From owner-multi6@ops.ietf.org Mon Dec 1 00:08:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25532 for ; Mon, 1 Dec 2003 00:08:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQgFG-000Nf2-GW for multi6-data@psg.com; Mon, 01 Dec 2003 05:05:14 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AQgF2-000Nd7-Hn for multi6@ops.ietf.org; Mon, 01 Dec 2003 05:05:01 +0000 Received: (qmail 25789 invoked from network); 1 Dec 2003 05:03:35 -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; 1 Dec 2003 05:03:35 -0000 Message-ID: <3FCACC7E.3060501@necom830.hpcl.titech.ac.jp> Date: Mon, 01 Dec 2003 14:07: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: dcrocker@brandenburg.com CC: Iljitsch van Beijnum , Multi6 Mailing List Subject: Re: delayed multihoming/mobility set-up References: <63AE30A8-193C-11D8-A52A-000A9598A184@kurtis.pp.se> <3FB9566A.4090000@necom830.hpcl.titech.ac.jp> <954CD888-1F2F-11D8-AC6B-000A95CD987A@muada.com> <102251632608.20031125075105@brandenburg.com> In-Reply-To: <102251632608.20031125075105@brandenburg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave Crocker; > Iljitsch, > > IvB> The reason that BGP > IvB> rerouting can take so long is that the RFC mandates a 90 second hold > IvB> time, And a 90 second hold time is already too long. > The reason that BGP has a long hold is because short times lead to route > flapping. > > This is an inherent property of doing route calculations. A scheme that > is too quick to change will be constantly changing. Hence the > assessment of a particular route always needs to be pretty slow to > change the assessment. And the definition on "too quick" is affected by time required for BGP route computation, IGP route propagation and so on, all of which are reduced with smaller routing table. I think hold time for EBGP peering over point to point optical ethernet should be (like SONET) several tens of milli seconds (though it violates BGP4). However, the same timing can not be applicable to IBGP peering. Have smaller global routing table and make BGP converge as quickly as that of telephone routing. > That is why I think the way to achieve quick response is with a model of > parallel paths. When one goes out, the other is already in use. (Of > course, this introduces the costs of out-of-order packets.) In this case, it does not help at all, as a notification of "one goes out" is delayed 90 or 180 seconds. Masataka Ohta From owner-multi6@ops.ietf.org Mon Dec 1 04:34:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02952 for ; Mon, 1 Dec 2003 04:34:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQkOb-0008bw-J4 for multi6-data@psg.com; Mon, 01 Dec 2003 09:31:09 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQkO7-0008ZL-2t for multi6@ops.ietf.org; Mon, 01 Dec 2003 09:30:39 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 0550C43166; Mon, 1 Dec 2003 10:30:38 +0100 (CET) Received: from lolo (unknown [163.117.139.227]) by smtp02.uc3m.es (Postfix) with SMTP id B3C6E9A0CC; Mon, 1 Dec 2003 10:30:37 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" , "Dave Crocker" Cc: Subject: RE: Some Comments on ID/Loc Separation Proposals Date: Mon, 1 Dec 2003 10:24:12 +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: <421EA354-2329-11D8-AA85-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 > > Endpoint > > > refers to "the fundamental entity of and end-end > > communication" [EID]. It is an end-system that participates > > in an association. Endpoints are distinguished from > > intermediate, infrastructure nodes and from hosts. > > An endpoint is an end-system but not a host: I think this isn't all > that clear. > > Personally, I prefer to talk about hosts, as this is a well-known > concept. I guess this is exactly the problem :-) People has a pre defined concept about what a host is, so they assume properties about it. That is why it is good to use a different term such as endpoint, that can be defined properly > The fact that there is some ambiguity because hosts can be > clustered and virtualized also isn't a huge surprise to most people, > and can be spelled out for good measure. I guess that something about the relation between a host and an endpoint can be inlcuded. > > If you want to stick to "endpoints" you should say whether an endpoint > is host that may or may not be virtual, a transport protocol or a > process. This has pretty serious consequences for the number of > identifiers that is necessary and some other stuff as well. For > instance, certain types of communication may be handled by more than a > single processes. When identifiers are tied to processes this makes > referral very complex. > > > Identifier > > > refers to a unique label for an endpoint. > > Hm, maybe this is just my English but to me it is unclear whether you > mean the identifier <-> endpoint relationship is 1-to-1, 1-to-n or > n-to-1, only that it isn't n-to-m. > good point i would say that the relation is n-to-1 but this should be defined and clarified in the text > I think "an identifier identifies a specific endpoint" is enough. > I think we need more than this, in order to be clear. The proposed text with a modification to explicitly define the n-to-1 relation should be good enough IMHO > > The label is used > > simply for distinguishing one endpoint from another. > > Because a locator is usually globally unique, it might be > > able to serve as an identifier. However this use will often > > suffer administrative and referential limitations as a > > global identifier for mobile endpoints. This is exemplified > > by the current problems experienced with the dual role of > > IP Addresses. > > This is too much text and largely not relevant for defining > "identifier". The only additional remark that's necessary is that an > identifier is independent of an endpoint's attachment to the network > ("location"). I guess that this is not what Dave is trying to say... the locator can be used as an identifier, since it is unique, but its usage as an identifier presents some limitations Regards. marcelo > > > As with others, I do not think it is useful to have ID refer to an > > interface. Stack, endpoint or process all seem more helpful. > > Absolutely. While multi6 is about site multihoming and not host > multihoming, it would be a mistake only allow jumping locators when > those locators are tied to the same interface. > > "Endpoint" is usable, but "stack" isn't a very good word as it will > probably confuse people who haven't followed what has happened in the > NSRG and identifying processes is too granular and dynamic, IMO. > > From owner-multi6@ops.ietf.org Mon Dec 1 04:34:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02972 for ; Mon, 1 Dec 2003 04:34:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQkOK-0008a5-FW for multi6-data@psg.com; Mon, 01 Dec 2003 09:30:52 +0000 Received: from [163.117.136.122] (helo=smtp.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQkO7-0008ZK-2x for multi6@ops.ietf.org; Mon, 01 Dec 2003 09:30:39 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id DC64143163; Mon, 1 Dec 2003 10:30:37 +0100 (CET) Received: from lolo (unknown [163.117.139.227]) by smtp02.uc3m.es (Postfix) with SMTP id CC7299A0CA; Mon, 1 Dec 2003 10:30:36 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Dave Crocker" , Subject: RE: Some Comments on ID/Loc Separation Proposals Date: Mon, 1 Dec 2003 10:24:12 +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: <5420088946.20031127153922@brandenburg.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 > > Speaking of 'stack', what definition text would folks like. The NSRG > paper introduces the construct nicely, but I'm not sure the text there > is what we should live with. > > For that matter, what is the difference between endpoint and stack? I don't see any difference between the definition of endpoint and stack... I would just keep one of them (i like endpoint better) regards, marcelo > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > > From owner-multi6@ops.ietf.org Mon Dec 1 08:05:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08963 for ; Mon, 1 Dec 2003 08:05:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQniO-000Gz4-1k for multi6-data@psg.com; Mon, 01 Dec 2003 13:03:48 +0000 Received: from [204.127.202.56] (helo=sccrmhc12.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQniC-000Gyf-1i for multi6@ops.ietf.org; Mon, 01 Dec 2003 13:03:36 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc12) with SMTP id <20031201130335012003ct0ie> (Authid: sdawkins@comcast.net); Mon, 1 Dec 2003 13:03:35 +0000 Message-ID: <004901c3b80b$87371170$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: Subject: Re: Some Comments on ID/Loc Separation Proposals Date: Mon, 1 Dec 2003 07:03:34 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.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 ----- Original Message ----- From: "marcelo bagnulo" To: "Dave Crocker" ; Sent: Monday, December 01, 2003 3:24 AM Subject: RE: Some Comments on ID/Loc Separation Proposals > > > > Speaking of 'stack', what definition text would folks like. The NSRG > > paper introduces the construct nicely, but I'm not sure the text there > > is what we should live with. > > > > For that matter, what is the difference between endpoint and stack? > > I don't see any difference between the definition of endpoint and stack... > I would just keep one of them (i like endpoint better) > regards, marcelo When I saw Dave's note, I wondered how "stack" mapped onto "dual-stack ipv4/ipv6". If everybody thinks "dual-stack" is still one stack for the purposes of this discussion, fine, but if we don't all have the same answer to this question, I like endpoint better, too. Spencer From owner-multi6@ops.ietf.org Mon Dec 1 12:20:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18487 for ; Mon, 1 Dec 2003 12:20:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQrh4-0001vH-GB for multi6-data@psg.com; Mon, 01 Dec 2003 17:18:42 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQrgr-0001uk-A6 for multi6@ops.ietf.org; Mon, 01 Dec 2003 17:18:29 +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, 1 Dec 2003 09:18:57 -0800 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 01 Dec 2003 09:18:28 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Dec 2003 09:18:10 -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, 1 Dec 2003 09:18:28 -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, 1 Dec 2003 09:18:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.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: delayed multihoming/mobility set-up Date: Mon, 1 Dec 2003 09:18:39 -0800 Message-ID: Thread-Topic: delayed multihoming/mobility set-up Thread-Index: AcO3zA70Fd+OkP+2QWGssaNGsl8LawAYLgzA From: "Christian Huitema" To: "Masataka Ohta" , Cc: "Iljitsch van Beijnum" , "Multi6 Mailing List" X-OriginalArrivalTime: 01 Dec 2003 17:18:28.0097 (UTC) FILETIME=[22A8D710:01C3B82F] 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 > > IvB> The reason that BGP > > IvB> rerouting can take so long is that the RFC mandates a 90 second > hold > > IvB> time, >=20 > And a 90 second hold time is already too long. ... which is why I am convinced that the solution to preserving existing communication is closest to "transport protocols" than "routing protocols". The time scale of transport protocols is the RTT; the time scale of routing protocols is the minute. If we wait for a routing event to be somehow signaled to the transport stack, the connection will be gone. The natural solution is to use a transport event, e.g. a retransmission timer. This event can trigger an end-to-end "connection rehoming" exchange. My preferred time-line would be: 1) Start a communication using one of the available pairs of src/dest addresses. 2) If the communication is determined to be worth it (i.e. last long enough), engage in "multi-homing signaling" to obtain a "set of equivalent addresses" 3) On a transport event such as retransmission time-out, probe alternate pairs of src/dest addresses, and pick a "better one" if available. I would note that a lot of the communication we have today do not meet the "worth it" requirement. The top applications in the Internet today are web pages, which mostly consist of a large number of very short exchanges, and p2p file sharing, which includes its own application level tools to deal with multi-homing.=20 -- Christian Huitema From owner-multi6@ops.ietf.org Mon Dec 1 13:46:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22340 for ; Mon, 1 Dec 2003 13:46:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQt2R-0006Ci-Dh for multi6-data@psg.com; Mon, 01 Dec 2003 18:44:51 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQt2F-0006CK-7D for multi6@ops.ietf.org; Mon, 01 Dec 2003 18:44:39 +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 hB1IiVUP014071; Mon, 1 Dec 2003 10:44:32 -0800 (PST) Received: from localhost (d-mpk17-89-243.SFBay.Sun.COM [129.146.89.243]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id hB1IiUQ21950; Mon, 1 Dec 2003 19:44:30 +0100 (MET) Date: Mon, 1 Dec 2003 10:44:31 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Some Comments on ID/Loc Separation Proposals To: Dave Crocker Cc: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <5420088946.20031127153922@brandenburg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Endpoint > > refers to "the fundamental entity of and end-end > communication" [EID]. It is an end-system that participates > in an association. Endpoints are distinguished from > intermediate, infrastructure nodes and from hosts. Dave, Do you intentionally want the definition of endpoint to be open to the endpoint being any of - (an instance of) the IP protocol processing on a node - a IP service access point (i.e. the point where the transport protocols attach to IP) - a transport service access point - something higher up in the protocol stack The reason I'm asking is because there are proposals that explore the first three in the list. If you want to keep the definition open to applying at different layers it would be good to make that very explicit in the definition. Erik From owner-multi6@ops.ietf.org Mon Dec 1 14:53:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24436 for ; Mon, 1 Dec 2003 14:53:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQu4o-000A5C-Cq for multi6-data@psg.com; Mon, 01 Dec 2003 19:51:22 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQu4a-000A42-KH for multi6@ops.ietf.org; Mon, 01 Dec 2003 19:51:08 +0000 Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hB1Juef05454; Mon, 1 Dec 2003 11:56:40 -0800 Date: Mon, 1 Dec 2003 08:25:00 -0800 From: Dave Crocker Reply-To: dcrocker@brandenburg.com Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <7078482331.20031201082500@brandenburg.com> To: Eliot Lear CC: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals In-Reply-To: <3FCA2C14.9020900@cisco.com> References: <5420088946.20031127153922@brandenburg.com> <421EA354-2329-11D8-AA85-000A95CD987A@muada.com> <3FCA2C14.9020900@cisco.com> 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=-3.3 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06, PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot, EL> Once so spelt out, an end point would would have been defined in all but EL> word, so why not define it? Personally I believe the term "host" has EL> become ambiguous, and so itself is worthy of a good clarification, if EL> not definition. I think that the term host is dandy for referring to a machine running IP on the Internet. We need a term for a finer-grained entity that is the processing unit for a transport association. Given usage of 'stack' and 'endpoint', it is worth considering how the two relate. Are the really the same thing, or is there a useful distinction that is worth keeping? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Mon Dec 1 14:54:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24454 for ; Mon, 1 Dec 2003 14:54:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQu66-000AAl-Kj for multi6-data@psg.com; Mon, 01 Dec 2003 19:52:42 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AQu5t-000A9p-8s for multi6@ops.ietf.org; Mon, 01 Dec 2003 19:52:29 +0000 Received: (qmail 28564 invoked from network); 1 Dec 2003 19:44:35 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 1 Dec 2003 19:44:35 -0000 Message-ID: <3FCB9AF0.6060308@necom830.hpcl.titech.ac.jp> Date: Tue, 02 Dec 2003 04:48:00 +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: dcrocker@brandenburg.com, Iljitsch van Beijnum , Multi6 Mailing List Subject: Re: delayed multihoming/mobility set-up References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.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 Christian; >>>IvB> The reason that BGP >>>IvB> rerouting can take so long is that the RFC mandates a 90 second >> >>hold >> >>>IvB> time, >> >>And a 90 second hold time is already too long. > ... which is why I am convinced that the solution to preserving existing > communication is closest to "transport protocols" than "routing > protocols". As you say "preserving", you really are talking about "connection", not "communication" in general. The proper argument is that preserving existing connection is a function of not the connectionless Internetworking layer but the transport layer (or above) But, note that your argument is insufficient ignoring simple UDP query-response type communication such as that of DNS. > The time scale of transport protocols is the RTT; the time > scale of routing protocols is the minute. If we wait for a routing event > to be somehow signaled to the transport stack, the connection will be > gone. The role of routing protocol is to try to keep the Internet connected at the connectinless Internetworking layer, which has nothing to do with connection of connection oriented protocols. In other types of network, routing protocols may operate both at L2, L3 and L4 to take care of keep preserving L4 connection. But, it is not the case with the Internet. > I would note that a lot of the communication we have today do not meet > the "worth it" requirement. The top applications in the Internet today > are web pages, which mostly consist of a large number of very short > exchanges, and p2p file sharing, which includes its own application > level tools to deal with multi-homing. You are connection oriented. The difficulty is not in "preserving". See above for a UDP example. Masataka Ohta From owner-multi6@ops.ietf.org Mon Dec 1 14:59:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24670 for ; Mon, 1 Dec 2003 14:59:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQuB5-000AXp-Ko for multi6-data@psg.com; Mon, 01 Dec 2003 19:57:51 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQu9h-000ARi-Ub for multi6@ops.ietf.org; Mon, 01 Dec 2003 19:56:26 +0000 Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hB1K37f05990; Mon, 1 Dec 2003 12:03:08 -0800 Date: Mon, 1 Dec 2003 11:59:11 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <17191332859.20031201115911@brandenburg.com> To: "marcelo bagnulo" CC: multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals In-Reply-To: References: <421EA354-2329-11D8-AA85-000A95CD987A@muada.com> 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=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> > The label is used >> > simply for distinguishing one endpoint from another. >> > Because a locator is usually globally unique, it might be >> > able to serve as an identifier. However this use will often >> > suffer administrative and referential limitations as a >> > global identifier for mobile endpoints. This is exemplified >> > by the current problems experienced with the dual role of >> > IP Addresses. >> >> This is too much text and largely not relevant for defining >> "identifier". The only additional remark that's necessary is that an >> identifier is independent of an endpoint's attachment to the network >> ("location"). mb> I guess that this is not what Dave is trying to say... mb> the locator can be used as an identifier, since it is unique, but its usage mb> as an identifier presents some limitations correct. The first sentence is the definition. The second sentence notes a type of string that can be used. The rest notes known problems with the string. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Mon Dec 1 15:08:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25459 for ; Mon, 1 Dec 2003 15:08:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQuK8-000B6C-Uv for multi6-data@psg.com; Mon, 01 Dec 2003 20:07:12 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AQuJu-000B5E-LT for multi6@ops.ietf.org; Mon, 01 Dec 2003 20:06:58 +0000 Received: from BBFUJIP.brandenburg.com (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hB1KDif06725; Mon, 1 Dec 2003 12:13:44 -0800 Date: Mon, 1 Dec 2003 12:09:47 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <11991968804.20031201120947@brandenburg.com> To: "Christian Huitema" CC: "Multi6 Mailing List" Subject: Re: delayed multihoming/mobility set-up In-Reply-To: References: 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=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> And a 90 second hold time is already too long. CH> ... which is why I am convinced that the solution to preserving existing CH> communication is closest to "transport protocols" than "routing CH> protocols". Many scenarios do not require the fast switchover that is being discussed here. For them, the IP-Endpoint (shim) module works fine, for mobility an for multihoming that is used for fall-back reliability. For highly responsive fail-over, multiple locator-pairs must already be fully functioning before they are needed. Otherwise, the concern about being overly responsive sets in, with the usual, attendant problem of thrashing the choice of path. For this scenario, I too believe that transport is the place to put the mechanism, because transport is where the congestion response information is assessed. However the Endpoint module still has quite a bit of utility. First, it is useful for unmodifie transport modules, such as classic TCP. Second, it can support the common Address Locator Pool. That's the idea behind SLAP. CH> 1) Start a communication using one of the available pairs of src/dest CH> addresses. CH> 2) If the communication is determined to be worth it (i.e. last long CH> enough), engage in "multi-homing signaling" to obtain a "set of CH> equivalent addresses" CH> 3) On a transport event such as retransmission time-out, probe alternate CH> pairs of src/dest addresses, and pick a "better one" if available. CH> I would note that a lot of the communication we have today do not meet CH> the "worth it" requirement. Yes. This was an interesting point that came out of the discussion the Pekka S. and I had, that he reported. What I had not appreciated was that the asyncrhonous control exchange that MAST does permits exactly this sort of long deferral of the control exchange, meaning that it often will not be done at all. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Mon Dec 1 15:11:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25781 for ; Mon, 1 Dec 2003 15:11:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQuNW-000BJU-J2 for multi6-data@psg.com; Mon, 01 Dec 2003 20:10:42 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AQuNJ-000BI7-N0 for multi6@ops.ietf.org; Mon, 01 Dec 2003 20:10:30 +0000 Received: (qmail 28683 invoked from network); 1 Dec 2003 20:09:17 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 1 Dec 2003 20:09:17 -0000 Message-ID: <3FCBA0B9.2090200@necom830.hpcl.titech.ac.jp> Date: Tue, 02 Dec 2003 05:12: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: dcrocker@brandenburg.com CC: Eliot Lear , Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals References: <5420088946.20031127153922@brandenburg.com> <421EA354-2329-11D8-AA85-000A95CD987A@muada.com> <3FCA2C14.9020900@cisco.com> <7078482331.20031201082500@brandenburg.com> In-Reply-To: <7078482331.20031201082500@brandenburg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.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 Dave; > We need a term for a finer-grained entity that is the processing > unit for a transport association. A transport layer protocol may or may not use the finer-grained entity, which is totally dependent on a specific transport layer protocol. Terminlogies for such an entity too, of course, is totally dependent on a specific transport layer protocol. Attempts to force all the transport layer protocols use a certain Internetworking layer property or terminology is the layer violation. Even TCP is not designed to work only over IP, as is stated in RFC793: In principle, the TCP should be able to operate above a wide spectrum of communication systems ranging from hard-wired connections to packet-switched or circuit-switched networks. or TCP is designed to work in a very general environment of interconnected networks. though its specification assumes IPv4. Masataka Ohta From owner-multi6@ops.ietf.org Mon Dec 1 21:01:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16133 for ; Mon, 1 Dec 2003 21:01:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AQzop-0002MM-2G for multi6-data@psg.com; Tue, 02 Dec 2003 01:59:15 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AQzoc-0002LT-CS for multi6@ops.ietf.org; Tue, 02 Dec 2003 01:59:03 +0000 Received: (qmail 29700 invoked from network); 2 Dec 2003 01:57:53 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 2 Dec 2003 01:57:53 -0000 Message-ID: <3FCBF269.3020005@necom830.hpcl.titech.ac.jp> Date: Tue, 02 Dec 2003 11:01: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: Dave Crocker CC: Christian Huitema , Multi6 Mailing List Subject: Re: delayed multihoming/mobility set-up References: <11991968804.20031201120947@brandenburg.com> In-Reply-To: <11991968804.20031201120947@brandenburg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.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 Dave; > CH> ... which is why I am convinced that the solution to preserving existing > CH> communication is closest to "transport protocols" than "routing > CH> protocols". > > Many scenarios do not require the fast switchover that is being > discussed here. For them, the IP-Endpoint (shim) module works fine, You implicitely assume TCP and its defact default timing, which is no good for various applications. Such senario MUST be taken care of not at the IP but at the TCP layer. > for mobility an for multihoming that is used for fall-back > reliability. Mixing timing for mobility and multhoming only confuses everything. For example, mobility needs mobility, not fall-back reliability. Masataka Ohta From owner-multi6@ops.ietf.org Tue Dec 2 05:17:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10618 for ; Tue, 2 Dec 2003 05:17:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AR7XL-0007u5-0K for multi6-data@psg.com; Tue, 02 Dec 2003 10:13:43 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AR7X8-0007tR-F6 for multi6@ops.ietf.org; Tue, 02 Dec 2003 10:13:30 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hB2ADtDP031256; Tue, 2 Dec 2003 11:13:57 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2AFFEB20-24B0-11D8-A441-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: delayed multihoming/mobility set-up Date: Tue, 2 Dec 2003 11:13:26 +0100 To: "Christian Huitema" X-Mailer: Apple Mail (2.606) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 1-dec-03, at 18:18, Christian Huitema wrote: > ... which is why I am convinced that the solution to preserving > existing > communication is closest to "transport protocols" than "routing > protocols". The time scale of transport protocols is the RTT; the time > scale of routing protocols is the minute. If we wait for a routing > event > to be somehow signaled to the transport stack, the connection will be > gone. The natural solution is to use a transport event, e.g. a > retransmission timer. This event can trigger an end-to-end "connection > rehoming" exchange. I don't necessarily agree that routing protocols by their nature can't do better than the minute timescale, but today BGP lives around that timescale and depending on routing has other downsides, such as the fact that a routing protocol has little information about which path is really better and they don't allow the use of multiple paths in a useful way. So I agree that we need to handle this end-to-end. > My preferred time-line would be: > 1) Start a communication using one of the available pairs of src/dest > addresses. > 2) If the communication is determined to be worth it (i.e. last long > enough), engage in "multi-homing signaling" to obtain a "set of > equivalent addresses" Hm, this is problematic. Simply exchanging addresses isn't good enough, as this allows for redirection attacks. So the addresses must be validated by using them in a way that can't be spoofed by a third party. I.e., one side must contact the other using a new address and include authentication information that tells the correspondent it's still talking to the same party. If we're doing this anyway there is little need to exchange the addresses beforehand. Depending on the type of rehoming authentication used it may be necessary to set up authentication state before rehoming happens. > 3) On a transport event such as retransmission time-out, probe > alternate > pairs of src/dest addresses, and pick a "better one" if available. Agree. Question: do we want to do this on a per transport session basis, or do we move an address and all transports running over it in one go when a rehoming event occurs? > I would note that a lot of the communication we have today do not meet > the "worth it" requirement. The top applications in the Internet today > are web pages, which mostly consist of a large number of very short > exchanges, and p2p file sharing, which includes its own application > level tools to deal with multi-homing. Even though it's probably not worth the trouble to protect the individual TCP sessions towards a web server (but protecting large downloads over HTTP would be very useful), it would still be good to have fairly seamless failover to another address when a web address fails. I'm sure Amazon or Ebay wouldn't want to run the risk of losing customers because of reachability issues by depending on web browsers to do the right thing. But this assumes the protection is active at the IP address level rather than the transport protocol level. From owner-multi6@ops.ietf.org Tue Dec 2 07:47:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14804 for ; Tue, 2 Dec 2003 07:47:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AR9uE-000Djr-Mo for multi6-data@psg.com; Tue, 02 Dec 2003 12:45:30 +0000 Received: from [204.127.202.56] (helo=sccrmhc12.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AR9u2-000DjZ-HB for multi6@ops.ietf.org; Tue, 02 Dec 2003 12:45:18 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc12) with SMTP id <200312021245170120052ff0e> (Authid: sdawkins@comcast.net); Tue, 2 Dec 2003 12:45:17 +0000 Message-ID: <00c001c3b8d2$23a22e20$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Multi6 Mailing List" References: <2AFFEB20-24B0-11D8-A441-000A95CD987A@muada.com> Subject: Re: delayed multihoming/mobility set-up Date: Tue, 2 Dec 2003 06:45:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just a couple of notes here... Spencer ----- Original Message ----- From: "Iljitsch van Beijnum" To: "Christian Huitema" Cc: "Multi6 Mailing List" Sent: Tuesday, December 02, 2003 4:13 AM Subject: Re: delayed multihoming/mobility set-up > On 1-dec-03, at 18:18, Christian Huitema wrote: > > > My preferred time-line would be: > > > 1) Start a communication using one of the available pairs of src/dest > > addresses. > > 2) If the communication is determined to be worth it (i.e. last long > > enough), engage in "multi-homing signaling" to obtain a "set of > > equivalent addresses" > > Hm, this is problematic. Simply exchanging addresses isn't good enough, > as this allows for redirection attacks. So the addresses must be > validated by using them in a way that can't be spoofed by a third > party. I.e., one side must contact the other using a new address and > include authentication information that tells the correspondent it's > still talking to the same party. If we're doing this anyway there is > little need to exchange the addresses beforehand. Depending on the type Well, the GPRS RTT on networks I've measured *is* around one second, so if we didn't have to wait until our WLAN address lost its connectivity to exchange addresses, that could be lovely... > of rehoming authentication used it may be necessary to set up > authentication state before rehoming happens. > > > 3) On a transport event such as retransmission time-out, probe > > alternate > > pairs of src/dest addresses, and pick a "better one" if available. > > Agree. > > Question: do we want to do this on a per transport session basis, or do > we move an address and all transports running over it in one go when a > rehoming event occurs? Well, someone got up in Minneapolis and said, "don't bother rehoming my e-mail connection, because I would rather keep retrieving e-mail over my WWAN connection than interrupt retrievals every time I lost my WLAN connection". If these seems desireable, it's probably per-transport-session; if not, it's probably per-address, unless we want to go down the ToS/CoS path. > > > I would note that a lot of the communication we have today do not meet > > the "worth it" requirement. The top applications in the Internet today > > are web pages, which mostly consist of a large number of very short > > exchanges, and p2p file sharing, which includes its own application > > level tools to deal with multi-homing. > > Even though it's probably not worth the trouble to protect the > individual TCP sessions towards a web server (but protecting large > downloads over HTTP would be very useful), it would still be good to > have fairly seamless failover to another address when a web address > fails. I'm sure Amazon or Ebay wouldn't want to run the risk of losing > customers because of reachability issues by depending on web browsers > to do the right thing. But this assumes the protection is active at the > IP address level rather than the transport protocol level. Christian's opinion is true for per-object HTTP connections, a little less true for persistent HTTP connections, little less true for persistent HTTP connections to a proxy, and a little less true for persistent HTTP connections when the browser is using pipelining. It's a pity that we can't include some notion of "this is a large object" in HTML, of course. Spencer From owner-multi6@ops.ietf.org Tue Dec 2 09:00:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17413 for ; Tue, 2 Dec 2003 09:00:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARB2j-000H1p-EP for multi6-data@psg.com; Tue, 02 Dec 2003 13:58:21 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ARB2W-000H1B-MA for multi6@ops.ietf.org; Tue, 02 Dec 2003 13:58:08 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3B4CD25B; Tue, 2 Dec 2003 14:58:07 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.227]) by smtp02.uc3m.es (Postfix) with SMTP id 232E4256; Tue, 2 Dec 2003 14:58:07 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Christian Huitema" , "Masataka Ohta" , Cc: "Iljitsch van Beijnum" , "Multi6 Mailing List" Subject: RE: delayed multihoming/mobility set-up Date: Tue, 2 Dec 2003 14:51:38 +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-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Christian, > My preferred time-line would be: I agree with most of this outline, just a question... > > 1) Start a communication using one of the available pairs of src/dest > addresses. > 2) If the communication is determined to be worth it (i.e. last long > enough), engage in "multi-homing signaling" to obtain a "set of > equivalent addresses" Wouldn't be possible to exchange additional information once that the outage has been detected? This sound a bit strange, i know... But suppose we are using something like SIM We start the communication using the AID a one locator without any kind of validation of the AID If no outage occurs, the communication continues and no extra overhead is introduced. If an outage occurs, the endpoints detect it (for instance helped by the transport or application layer) At that time, they start using different source addresses and see if they reach the other end (this packet has to contain also some validation information, linking the initial AID with the new source locator) Now, when the other end receives a packet with a different source address (and validation information), it starts sending to this new address. This approach allows to avoid any additional packet exchange until an outage occurs (when it is needed) Do you think this may work? regards, marcelo > 3) On a transport event such as retransmission time-out, probe alternate > pairs of src/dest addresses, and pick a "better one" if available. > > I would note that a lot of the communication we have today do not meet > the "worth it" requirement. The top applications in the Internet today > are web pages, which mostly consist of a large number of very short > exchanges, and p2p file sharing, which includes its own application > level tools to deal with multi-homing. > > -- Christian Huitema > From owner-multi6@ops.ietf.org Tue Dec 2 10:53:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22978 for ; Tue, 2 Dec 2003 10:53:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ARCoJ-000LTF-MZ for multi6-data@psg.com; Tue, 02 Dec 2003 15:51:35 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ARCnx-000LRl-ER for multi6@ops.ietf.org; Tue, 02 Dec 2003 15:51:14 +0000 Received: (qmail 31942 invoked from network); 2 Dec 2003 15:50:15 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 2 Dec 2003 15:50:15 -0000 Message-ID: <3FCCB576.3000606@necom830.hpcl.titech.ac.jp> Date: Wed, 03 Dec 2003 00:53:26 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Christian Huitema , Multi6 Mailing List Subject: Re: delayed multihoming/mobility set-up References: <2AFFEB20-24B0-11D8-A441-000A95CD987A@muada.com> In-Reply-To: <2AFFEB20-24B0-11D8-A441-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch; >> 1) Start a communication using one of the available pairs of src/dest >> addresses. >> 2) If the communication is determined to be worth it (i.e. last long >> enough), engage in "multi-homing signaling" to obtain a "set of >> equivalent addresses" > > > Hm, this is problematic. Simply exchanging addresses isn't good enough, > as this allows for redirection attacks. So the addresses must be > validated by using them in a way that can't be spoofed by a third party. > I.e., one side must contact the other using a new address and include > authentication information that tells the correspondent it's still > talking to the same party. If we're doing this anyway there is little > need to exchange the addresses beforehand. Redirection is inherent to the Internet and is no issue. The approach is simply wrong, because it is connection oriented. > Depending on the type of > rehoming authentication used it may be necessary to set up > authentication state before rehoming happens. Rehoming has nothing to do with multihoming. A singly homed host can rehome. A dual homed host may keep using the homes forever without rehoming. Masataka Ohta From owner-multi6@ops.ietf.org Thu Dec 4 16:59:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18945 for ; Thu, 4 Dec 2003 16:59:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AS1TE-000All-Gf for multi6-data@psg.com; Thu, 04 Dec 2003 21:57:12 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AS1T0-000AlI-PU for multi6@ops.ietf.org; Thu, 04 Dec 2003 21:56:58 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id hB4M3lf01517; Thu, 4 Dec 2003 14:03:47 -0800 Date: Thu, 4 Dec 2003 13:56:39 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <167222013518.20031204135639@brandenburg.com> To: Erik Nordmark CC: multi6@ops.ietf.org Subject: Re: Some Comments on ID/Loc Separation Proposals In-Reply-To: References: "Your message with ID" <5420088946.20031127153922@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, EN> Do you intentionally want the definition of endpoint to be open to EN> the endpoint being any of EN> - (an instance of) the IP protocol processing on a node EN> - a IP service access point (i.e. the point where the transport protocols EN> attach to IP) EN> - a transport service access point EN> - something higher up in the protocol stack 1. I want the term to be precise. Anything in the definition that permits ambiguity is a bad thing, in my view. So you should assume that any of the text I offered that results in ambiguity is an error in my text and needs to be fixed. 2. The difference in focus, between IP processing, transport processing, and application processing is exactly what makes all this difficult. I am loathe to believe that we need lots of new terms. So I think we need to understand exactly how we want to use this one (or two) new term(s) and then calculate the definition back from it. And, yes, the fact that I am not giving you a more concrete response is intentional. I've offered some specific text. I want others to fix it. (Or, rather, I can't come up with anything better...) EN> The reason I'm asking is because there are proposals that explore the EN> first three in the list. If you want to keep the definition open EN> to applying at different layers it would be good to make that very explicit EN> in the definition. I think it will serve us well to _start_ with reference to a local instance of an application, and then derive text back from it. Focusing only on the lower layers causes us to miss what is most interesting and useful, I fear. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Fri Dec 5 06:06:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00053 for ; Fri, 5 Dec 2003 06:06:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASDkI-000LDg-Gn for multi6-data@psg.com; Fri, 05 Dec 2003 11:03:38 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASDk5-000LAV-Iz for multi6@ops.ietf.org; Fri, 05 Dec 2003 11:03:25 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8E8F4175 for ; Fri, 5 Dec 2003 12:03:24 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.227]) by smtp01.uc3m.es (Postfix) with SMTP id 7BB9E172 for ; Fri, 5 Dec 2003 12:03:24 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: Subject: additional attack for multi6 threat draft? Date: Fri, 5 Dec 2003 11:56:52 +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-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Perhaps there is an additional attack that should be included in the threat draft The attack would be something like this an attacker X wants to impersonate another host B in future communications initiated by A to B (i will use mip notation to simplify) X sends to A a sort of BU binding X as the CoA and B as the HoA (in order to do this X may need to be on the path between A and B, but if this is only for a short period of time that attack can be successful) If the attacker has a mean to maintain the binding in host A (for instance sending periodic pings to it or other packets that will end up being discarded by the ULP), then when eventually A wants to communicate with B, A will send packets to X Do you think this is a real threat? IMHO, this is the real attack that can be prevented by limiting BCE in mip6. I think this threat is not considered in the threat draft... IMHO this is related to the attacks included in the 4.1.2 section about premeditated redirection but i don't think that it is inlcuded there. the example considered in the threat draft is that A and B will comunicate, so X sends a BU to B containing A as a HoA and X as a CoA then the described attack continues considering that A tries to communicate with B and the problems that arise The attack described above is about the case when B initiates the communication. IMHO this is potentially more dangerous, because probably X will be able to impersonate A, and B will actually believe that it is communicating with A when he is actually communicating with X So if you think this is important enough to be included, i can try to write a paragraph about it if you want. Regards, marcelo From owner-multi6@ops.ietf.org Fri Dec 5 06:35:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00814 for ; Fri, 5 Dec 2003 06:35:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASEE2-000MpA-8j for multi6-data@psg.com; Fri, 05 Dec 2003 11:34:22 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ASED1-000Mlq-Hr for multi6@ops.ietf.org; Fri, 05 Dec 2003 11:33:19 +0000 Received: (qmail 47305 invoked from network); 5 Dec 2003 11:33:12 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 5 Dec 2003 11:33:12 -0000 Message-ID: <3FD06D89.7040401@necom830.hpcl.titech.ac.jp> Date: Fri, 05 Dec 2003 20:35:37 +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: additional attack for multi6 threat draft? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; > X sends to A a sort of BU binding X as the CoA and B as the HoA (in order to > do this X may need to be on the path between A and B, but if this is only > for a short period of time that attack can be successful) MITM can do almost anything, of course. > Do you think this is a real threat? No, of course. > the example considered in the threat draft is that A and B will comunicate, ALl you need is a threat draft with plain IP. > (i will use mip notation to simplify) Just FYI, MIPv6 or any mobility protocol with triangular elimination can be a cause of new type of threat, even though no MITM is involed. However, triangular emilination is an important feature of MIPv6 and it has nothing to do with multi6. Masataka Ohta From owner-multi6@ops.ietf.org Fri Dec 5 06:59:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01736 for ; Fri, 5 Dec 2003 06:59:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASEb3-000O4w-3t for multi6-data@psg.com; Fri, 05 Dec 2003 11:58:09 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASEaq-000O4H-Cs for multi6@ops.ietf.org; Fri, 05 Dec 2003 11:57:56 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hB5BwIDP080713; Fri, 5 Dec 2003 12:58:18 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <167222013518.20031204135639@brandenburg.com> References: "Your message with ID" <5420088946.20031127153922@brandenburg.com> <167222013518.20031204135639@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <40ACF345-271A-11D8-B47D-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: Some Comments on ID/Loc Separation Proposals Date: Fri, 5 Dec 2003 12:57:51 +0100 To: Dave Crocker X-Mailer: Apple Mail (2.606) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 4-dec-03, at 22:56, Dave Crocker wrote: > EN> - (an instance of) the IP protocol processing on a node > EN> - a IP service access point (i.e. the point where the > EN> transport protocols attach to IP) > EN> - a transport service access point > EN> - something higher up in the protocol stack [...] > And, yes, the fact that I am not giving you a more concrete response > is intentional. I've offered some specific text. I want others to fix > it. (Or, rather, I can't come up with anything better...) We can't fix your definition for you if we don't know what you want to define... > I think it will serve us well to _start_ with reference to a local > instance of an application, and then derive text back from it. > Focusing only on the lower layers causes us to miss what is most > interesting and useful, I fear. Aggregating processes into applications, applications under a single ULP and ULPs under IP helps minimize the amount of work that an implementation needs to do, which is good CPU/bandwidth and delay wise. From owner-multi6@ops.ietf.org Fri Dec 5 11:47:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13114 for ; Fri, 5 Dec 2003 11:47:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASJ4e-00047G-EL for multi6-data@psg.com; Fri, 05 Dec 2003 16:45:00 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASJ4R-00046X-1y for multi6@ops.ietf.org; Fri, 05 Dec 2003 16:44:47 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F1FEA1D7; Fri, 5 Dec 2003 17:44:45 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.227]) by smtp01.uc3m.es (Postfix) with SMTP id C96BD1D5; Fri, 5 Dec 2003 17:44:45 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" Cc: Subject: RE: additional attack for multi6 threat draft? Date: Fri, 5 Dec 2003 17:38:12 +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: <3FD06D89.7040401@necom830.hpcl.titech.ac.jp> Importance: Normal X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > X sends to A a sort of BU binding X as the CoA and B as the HoA > (in order to > > do this X may need to be on the path between A and B, but if > this is only > > for a short period of time that attack can be successful) > > MITM can do almost anything, of course. Well, this is not striclty related with MiTM attack, but with redirection for future usage, let me try to explain. some multihoming support mechanism send a message from one node to its correspondent node on a communication that basically contians the following information: I am A, i.e. my identifier is A and I am located at B, i.e. my locator is B in sum this means that A can be reached at location B The receiver of such message has to verify both the identity and the location If the location is not verified, flooding attacks are possible If the identity is not verified, identity can be hijacked Direct impersonation attacks are those where the attacker is the one that attempts to establish the communication pretending to be another node (which are already considered in the draft IMHO) The attack that i am considering is about hijacking identitity but not in a direct form, as above but in a reverse form. In this case hte attacker creates some false state in the victim, so that in the future, when the victim attempts to communicate with a given server, it will direct its packets to the attacker,(who will be able to impersonate the server) Now, there are different proposals to verify the identity, depending on the type of identifier that it is being used. If ip addresses are used as identifiers (as in the case of mip), return routability can be used to verify the identity. the problem in this case, is that the attacker can play as a MITM for a *limited* period of time and manage to beat the verification mechanism as long as the acquired authorization information is valid. This implies that return routability cannot be used to protect from this attacks, since this allows transient MITM to achieve the same effect of permanent MITM, which IMHO is bad. So, the proposed attack is not really related with MITM, but is more generic However, transient MITM can manage to launch this attack when some specific solution (such as return routability) are used (during the lifetime of the verification information in the attacked node) > > > Do you think this is a real threat? > > No, of course. > > > the example considered in the threat draft is that A and B > will comunicate, > > ALl you need is a threat draft with plain IP. > > > (i will use mip notation to simplify) > > Just FYI, MIPv6 or any mobility protocol with triangular > elimination can be a cause of new type of threat, even > though no MITM is involed. > > However, triangular emilination is an important feature of MIPv6 > and it has nothing to do with multi6. I was just using mip terminology in order to make an example, but i guess this was not a good choice, sorry for the confusion that this may have caused. Regards, marcelo > > Masataka Ohta > > From owner-multi6@ops.ietf.org Sat Dec 6 11:36:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13163 for ; Sat, 6 Dec 2003 11:36:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASfL8-000GH5-5u for multi6-data@psg.com; Sat, 06 Dec 2003 16:31:30 +0000 Received: from [195.212.29.156] (helo=mtagate7.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASfKo-000GEm-63 for multi6@ops.ietf.org; Sat, 06 Dec 2003 16:31:10 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB6GV6wj045342; Sat, 6 Dec 2003 16:31:06 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB6GV6Tj244994; Sat, 6 Dec 2003 17:31:06 +0100 Received: from zurich.ibm.com ([9.145.151.94]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA25700; Sat, 6 Dec 2003 17:31:03 +0100 Message-ID: <3FD1FB9A.FCDA0A3F@zurich.ibm.com> Date: Sat, 06 Dec 2003 16:54: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: Spencer Dawkins CC: Multi6 Mailing List Subject: Re: delayed multihoming/mobility set-up References: <2AFFEB20-24B0-11D8-A441-000A95CD987A@muada.com> <00c001c3b8d2$23a22e20$0400a8c0@DFNJGL21> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit One of our current objectives is to start architectural breakdown and analysis. It seems to me there is an architectural boundary right in this thread - something to do with separating the detection of an address dropout (the address in use is suddenly no good) from fixing it (fast recovery a la SCTP if we care, or waiting for network layer and routing to select a new address if we are not in a hurry). Brian Spencer Dawkins wrote: > > Just a couple of notes here... > > Spencer > > ----- Original Message ----- > From: "Iljitsch van Beijnum" > To: "Christian Huitema" > Cc: "Multi6 Mailing List" > Sent: Tuesday, December 02, 2003 4:13 AM > Subject: Re: delayed multihoming/mobility set-up > > > On 1-dec-03, at 18:18, Christian Huitema wrote: > > > > > My preferred time-line would be: > > > > > 1) Start a communication using one of the available pairs of > src/dest > > > addresses. > > > 2) If the communication is determined to be worth it (i.e. last > long > > > enough), engage in "multi-homing signaling" to obtain a "set of > > > equivalent addresses" > > > > Hm, this is problematic. Simply exchanging addresses isn't good > enough, > > as this allows for redirection attacks. So the addresses must be > > validated by using them in a way that can't be spoofed by a third > > party. I.e., one side must contact the other using a new address and > > include authentication information that tells the correspondent it's > > still talking to the same party. If we're doing this anyway there is > > little need to exchange the addresses beforehand. Depending on the > type > > Well, the GPRS RTT on networks I've measured *is* around one second, > so if we didn't have to wait until our WLAN address lost its > connectivity to exchange addresses, that could be lovely... > > > of rehoming authentication used it may be necessary to set up > > authentication state before rehoming happens. > > > > > 3) On a transport event such as retransmission time-out, probe > > > alternate > > > pairs of src/dest addresses, and pick a "better one" if available. > > > > Agree. > > > > Question: do we want to do this on a per transport session basis, or > do > > we move an address and all transports running over it in one go when > a > > rehoming event occurs? > > Well, someone got up in Minneapolis and said, "don't bother rehoming > my e-mail connection, because I would rather keep retrieving e-mail > over my WWAN connection than interrupt retrievals every time I lost my > WLAN connection". If these seems desireable, it's probably > per-transport-session; if not, it's probably per-address, unless we > want to go down the ToS/CoS path. > > > > > > I would note that a lot of the communication we have today do not > meet > > > the "worth it" requirement. The top applications in the Internet > today > > > are web pages, which mostly consist of a large number of very > short > > > exchanges, and p2p file sharing, which includes its own > application > > > level tools to deal with multi-homing. > > > > Even though it's probably not worth the trouble to protect the > > individual TCP sessions towards a web server (but protecting large > > downloads over HTTP would be very useful), it would still be good to > > have fairly seamless failover to another address when a web address > > fails. I'm sure Amazon or Ebay wouldn't want to run the risk of > losing > > customers because of reachability issues by depending on web > browsers > > to do the right thing. But this assumes the protection is active at > the > > IP address level rather than the transport protocol level. > > Christian's opinion is true for per-object HTTP connections, a little > less true for persistent HTTP connections, little less true for > persistent HTTP connections to a proxy, and a little less true for > persistent HTTP connections when the browser is using pipelining. It's > a pity that we can't include some notion of "this is a large object" > in HTML, of course. > > Spencer -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-multi6@ops.ietf.org Sat Dec 6 11:36:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13187 for ; Sat, 6 Dec 2003 11:36:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASfLM-000GHZ-Lu for multi6-data@psg.com; Sat, 06 Dec 2003 16:31:44 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASfL1-000GGj-8U for multi6@ops.ietf.org; Sat, 06 Dec 2003 16:31:23 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB6GVDHf111784; Sat, 6 Dec 2003 16:31:13 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB6GVDd9049168; Sat, 6 Dec 2003 17:31:14 +0100 Received: from zurich.ibm.com ([9.145.151.94]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA25706; Sat, 6 Dec 2003 17:31:11 +0100 Message-ID: <3FD2033D.F15984CB@zurich.ibm.com> Date: Sat, 06 Dec 2003 17:26: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: Dave Crocker CC: multi6@ops.ietf.org Subject: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: <5420088946.20031127153922@brandenburg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit After some travel and some flu, I've caught up with this thread, but I think it's clearer to comment on Dave's original post. Firstly, co-chair hat on, we need consistent terminology. When we use a word, we should all try to use it in the same sense. In the end, we may need a specific multi6 terminology draft. It is also best if we use existing definitions rather than inventing our own with subtle changes. So, for example, if we do use "stack" let's agree on the NSRG definition unless we have a very strong reason to change it. Otherwise, confusion lies ahead. Co-chair hat off. Personal comments below. Dave Crocker wrote: > > Folks, > > draft-crocker-mast-analysis (which will be > draft-crocker-multiaddr-analysis in its next version) has a section > for defining some terms. The section has been prompted by exactly the > kind of vagueness that the current thread is also trying to fix. > > My primary interest is in having precise definitions that we all find > useful and use consistently. Some of the current versions of > definitions in the draft are: > > Endpoint > > refers to "the fundamental entity of and end-end > communication" [EID]. It is an end-system that participates > in an association. Endpoints are distinguished from > intermediate, infrastructure nodes and from hosts. Yes. But this is too generic to be really very useful... and trying to get more precision always ends in a rat hole. > > Identifier > > refers to a unique label for an endpoint. The label is used > simply for distinguishing one endpoint from another. But to use OSI terminology, this doesn't tell me enough, because I don't know whether you are talking about a layer 2, 3, 4 or higher endpoint. That's the advantage of "stack" - we know it's layer 3. > Because a locator is usually globally unique, it might be I wish. But every single time I travel, I find myself ending up with an identifier that *isn't* globally unique. I don't think "usually" is at all accurate. "supposedly unique" might be more accurate. > able to serve as an identifier. However this use will often > suffer administrative and referential limitations as a > global identifier for mobile endpoints. This is exemplified > by the current problems experienced with the dual role of > IP Addresses. I don't think so. You're correct of course that id/loc overlap is a problem with mobility. But the problems *today* are caused mainly by non-uniqueness and that is what is exemplified each time you hook up in a hotel. > > Suggestions for improving the text are eagerly sought. > > As with others, I do not think it is useful to have ID refer to an > interface. Stack, endpoint or process all seem more helpful. True. Interfaces are a somewhat elastic concept and not interesting at systems level. Personally I prefer NSRG-stack to endpoint, because as mentioned above it has more precision. > > Speaking of 'stack', what definition text would folks like. The NSRG > paper introduces the construct nicely, but I'm not sure the text there > is what we should live with. Do you have precise criticisms of that definition? > > For that matter, what is the difference between endpoint and stack? As an ex-NSRG member, I can tell you that "stack" was chosen because people couldn't reach precise consensus on what "end point" means. Brian From owner-multi6@ops.ietf.org Sat Dec 6 15:12:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18612 for ; Sat, 6 Dec 2003 15:12:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASiiP-0007Sv-CM for multi6-data@psg.com; Sat, 06 Dec 2003 20:07:45 +0000 Received: from [204.127.202.56] (helo=sccrmhc12.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASiiC-0007SX-Q9 for multi6@ops.ietf.org; Sat, 06 Dec 2003 20:07:32 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc12) with SMTP id <2003120620073101200jg6r6e> (Authid: sdawkins@comcast.net); Sat, 6 Dec 2003 20:07:31 +0000 Message-ID: <00f101c3bc34$93eb0480$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <5420088946.20031127153922@brandenburg.com> <3FD2033D.F15984CB@zurich.ibm.com> Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] Date: Sat, 6 Dec 2003 14:07:28 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear Brian, Excellent. So we have someone who can channel the spirit of NSRG... You may have been buried while traveling and recovering (and I apologize for contributing to your e-mail load), but I wonder if you could comment on my question about "dual-stack" - is a dual-stacked host one thing or two, in the NSRG sense of the term "stack"? Spencer ----- Original Message ----- From: "Brian E Carpenter" To: "Dave Crocker" Cc: Sent: Saturday, December 06, 2003 10:26 AM Subject: Terminology [Re: Some Comments on ID/Loc Separation Proposals] > After some travel and some flu, I've caught up with this thread, but I > think it's clearer to comment on Dave's original post. > > Firstly, co-chair hat on, we need consistent terminology. When we use a > word, we should all try to use it in the same sense. In the end, we may need > a specific multi6 terminology draft. It is also best if we use existing > definitions rather than inventing our own with subtle changes. So, for example, > if we do use "stack" let's agree on the NSRG definition unless we have a > very strong reason to change it. Otherwise, confusion lies ahead. > > Co-chair hat off. Personal comments below. > > Dave Crocker wrote: > > > > Folks, > > > > draft-crocker-mast-analysis (which will be > > draft-crocker-multiaddr-analysis in its next version) has a section > > for defining some terms. The section has been prompted by exactly the > > kind of vagueness that the current thread is also trying to fix. > > > > My primary interest is in having precise definitions that we all find > > useful and use consistently. Some of the current versions of > > definitions in the draft are: > > > > Endpoint > > > > refers to "the fundamental entity of and end-end > > communication" [EID]. It is an end-system that participates > > in an association. Endpoints are distinguished from > > intermediate, infrastructure nodes and from hosts. > > Yes. But this is too generic to be really very useful... and trying to > get more precision always ends in a rat hole. > > > > > Identifier > > > > refers to a unique label for an endpoint. The label is used > > simply for distinguishing one endpoint from another. > > But to use OSI terminology, this doesn't tell me enough, because I don't know > whether you are talking about a layer 2, 3, 4 or higher endpoint. That's the > advantage of "stack" - we know it's layer 3. > > > Because a locator is usually globally unique, it might be > > I wish. But every single time I travel, I find myself ending up with an > identifier that *isn't* globally unique. I don't think "usually" is at all > accurate. "supposedly unique" might be more accurate. > > > able to serve as an identifier. However this use will often > > suffer administrative and referential limitations as a > > global identifier for mobile endpoints. This is exemplified > > by the current problems experienced with the dual role of > > IP Addresses. > > I don't think so. You're correct of course that id/loc overlap is a problem > with mobility. But the problems *today* are caused mainly by non-uniqueness > and that is what is exemplified each time you hook up in a hotel. > > > > > Suggestions for improving the text are eagerly sought. > > > > As with others, I do not think it is useful to have ID refer to an > > interface. Stack, endpoint or process all seem more helpful. > > True. Interfaces are a somewhat elastic concept and not interesting > at systems level. Personally I prefer NSRG-stack to endpoint, because > as mentioned above it has more precision. > > > > > Speaking of 'stack', what definition text would folks like. The NSRG > > paper introduces the construct nicely, but I'm not sure the text there > > is what we should live with. > > Do you have precise criticisms of that definition? > > > > > For that matter, what is the difference between endpoint and stack? > > As an ex-NSRG member, I can tell you that "stack" was chosen because > people couldn't reach precise consensus on what "end point" means. > > Brian > > From owner-multi6@ops.ietf.org Sat Dec 6 17:49:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23153 for ; Sat, 6 Dec 2003 17:49:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASlCO-000MIu-G9 for multi6-data@psg.com; Sat, 06 Dec 2003 22:46:52 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ASlC9-000MIA-Kl for multi6@ops.ietf.org; Sat, 06 Dec 2003 22:46:38 +0000 Received: (qmail 53956 invoked from network); 6 Dec 2003 22:46:56 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 6 Dec 2003 22:46:56 -0000 Message-ID: <3FD25CD7.2070101@necom830.hpcl.titech.ac.jp> Date: Sun, 07 Dec 2003 07:48: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: Brian E Carpenter CC: Spencer Dawkins , Multi6 Mailing List Subject: Re: delayed multihoming/mobility set-up References: <2AFFEB20-24B0-11D8-A441-000A95CD987A@muada.com> <00c001c3b8d2$23a22e20$0400a8c0@DFNJGL21> <3FD1FB9A.FCDA0A3F@zurich.ibm.com> In-Reply-To: <3FD1FB9A.FCDA0A3F@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > One of our current objectives is to start architectural breakdown > and analysis. Huh? At Minneapolis, you denied my proposal to have architectural document, because most of us can 't do it. Why and how have you changed your mind? Masataka Ohta From owner-multi6@ops.ietf.org Sat Dec 6 17:54:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23219 for ; Sat, 6 Dec 2003 17:54:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASlI8-000N1B-Lx for multi6-data@psg.com; Sat, 06 Dec 2003 22:52:48 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ASlHw-000N0S-Ng for multi6@ops.ietf.org; Sat, 06 Dec 2003 22:52:37 +0000 Received: (qmail 53969 invoked from network); 6 Dec 2003 22:52:56 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 6 Dec 2003 22:52:56 -0000 Message-ID: <3FD25E3F.5070605@necom830.hpcl.titech.ac.jp> Date: Sun, 07 Dec 2003 07:54: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: Brian E Carpenter CC: Dave Crocker , multi6@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: <5420088946.20031127153922@brandenburg.com> <3FD2033D.F15984CB@zurich.ibm.com> In-Reply-To: <3FD2033D.F15984CB@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > It is also best if we use existing > definitions rather than inventing our own with subtle changes. It is best not to introduce any terminology, even though someone recently gave some random definition on some word. > So, for example, > if we do use "stack" Don't try to introduce useless terminology. Masataka Ohta From owner-multi6@ops.ietf.org Sat Dec 6 18:01:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23450 for ; Sat, 6 Dec 2003 18:01:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASlP8-000Nu7-1j for multi6-data@psg.com; Sat, 06 Dec 2003 23:00:02 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASlOv-000Ntb-HZ for multi6@ops.ietf.org; Sat, 06 Dec 2003 22:59:49 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1AF2686AE5; Sat, 6 Dec 2003 17:59:49 -0500 (EST) To: multi6@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] Cc: jnc@mercury.lcs.mit.edu Message-Id: <20031206225949.1AF2686AE5@mercury.lcs.mit.edu> Date: Sat, 6 Dec 2003 17:59:49 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Spencer Dawkins" > So we have someone who can channel the spirit of NSRG... Several people, actually... > I wonder if you could comment on my question about "dual-stack" - is a > dual-stacked host one thing or two, in the NSRG sense of the term > "stack"? The thing is, I think part of the reason the NSRG settled on the term "stack" (and I don't agree that Brian's take on why is complete, but I'll get to that separately) is that it was *not* a carefully defined term, and so people could agree that we needed to name "stacks" without coming to complete agreement on what a "stack" was. I'm not sure the NSRG ever did come to any kind of consensus on what a "stack" was - but I'm pretty sure it had overtones of a collection of things at *different* layers, including the application - as in "the complete protocol stack". For myself, to answer a previous question from Dave, I never could see a clear difference between "stack" and "endpoint" (as originally defined in http://users.exis.net/~jnc/tech/endpoints.txt). If anyone can clearly explain to me the difference between a "stack" and an "endpoint", I'd be interested - but in the absence of such a clear distinction, I'll continue to treat them as synoonyms. So in that context, using the definition of endpoint as "a fate-sharing region which is one end of an end-end communication", your question does not have a definite answer, because it depends on how the "dual-stack" host is implemented. If the two protocol stacks are inextracably bound together (and probably to that machine as well), then they are a single "endpoint", and thus a single "NSRG stack". (They still might have different *names* in each protocol stack - remember that a *name for a thing* is NOT *the thing itself*.) If they are implemented such that either protocol stack can up and go off to another machine, or something, then yeah they are separate endpoints/N-stacks. Noel From owner-multi6@ops.ietf.org Sat Dec 6 18:27:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25563 for ; Sat, 6 Dec 2003 18:27:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASlnv-0000Jq-C5 for multi6-data@psg.com; Sat, 06 Dec 2003 23:25:39 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ASlni-0000J9-Un for multi6@ops.ietf.org; Sat, 06 Dec 2003 23:25:27 +0000 Received: (qmail 54079 invoked from network); 6 Dec 2003 23:25:47 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 6 Dec 2003 23:25:47 -0000 Message-ID: <3FD265F1.5030106@necom830.hpcl.titech.ac.jp> Date: Sun, 07 Dec 2003 08:27:45 +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: additional attack for multi6 threat draft? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; >>>for a short period of time that attack can be successful) >> >>MITM can do almost anything, of course. > Well, this is not striclty related with MiTM attack, but with redirection > for future usage, let me try to explain. X on the same shared link as A is a specific form of MITM. > If ip addresses are used as identifiers (as in the case of mip), return > routability can be used to verify the identity. > the problem in this case, is that the attacker can play as a MITM for a > *limited* period of time and manage to beat the verification mechanism as > long as the acquired authorization information is valid. Yes, it is a MITM. As a MITM, an attacker can, for example, contaminate DNS cache for persistent effect. > This implies that return routability cannot be used to protect from this > attacks, since this allows transient MITM to achieve the same effect of > permanent MITM, which IMHO is bad. It is merely that RR can not be a protection against MITM. That is a generic statement. > So, the proposed attack is not really related with MITM, but is more generic The attack is a specific, not generic, form of MITM attack. > However, transient MITM can manage to launch this attack when some specific > solution (such as return routability) are used (during the lifetime of the > verification information in the attacked node) DoS is so easy. DoS by MITM is totally destructive that almost no security mechanism works. If you don't assume PKI, MITM will invalidate both cookies and public key cryptographic technologies including but not limited to DH. If you assume PKI, compromised CAs are virtually MITM that there is no real added security. ISPs are as realiable as CAs that there is no point on relying on PKI instead of RR. It should also be noted that, lacking cook protection, DoS effect of computationally expensive public key cryptography is fatal. In either case, attack by transient MITM at the time of initial cryptographic computation (with DH or PKI) will be effective for the lifetime. The only meaningful protection is by having common secret in advance and althenticate all the packets, though the approach does not scale. So far, nothing is mult6 specific. Masataka Ohta From owner-multi6@ops.ietf.org Sun Dec 7 05:39:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19809 for ; Sun, 7 Dec 2003 05:39:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ASwHu-000BXC-Hm for multi6-data@psg.com; Sun, 07 Dec 2003 10:37:18 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ASwHh-000BWQ-PM for multi6@ops.ietf.org; Sun, 07 Dec 2003 10:37:05 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 04FE6609; Sun, 7 Dec 2003 11:37:05 +0100 (CET) Received: from lolo (unknown [163.117.252.56]) by smtp01.uc3m.es (Postfix) with SMTP id C6A7F621; Sun, 7 Dec 2003 11:37:03 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" Cc: Subject: RE: additional attack for multi6 threat draft? Date: Sun, 7 Dec 2003 11:30:30 +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: <3FD265F1.5030106@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Well, this is not striclty related with MiTM attack, but with > redirection > > for future usage, let me try to explain. > > X on the same shared link as A is a specific form of MITM. > > > If ip addresses are used as identifiers (as in the case of mip), return > > routability can be used to verify the identity. > > the problem in this case, is that the attacker can play as a MITM for a > > *limited* period of time and manage to beat the verification > mechanism as > > long as the acquired authorization information is valid. > > Yes, it is a MITM. in THIS case, is MiTM for a limited period of time. (Please note the difference between an attack that requires MiTM during the complete attack and an attack that only requires MiTM during a short period of time and allowing that the attack to go on after the attacker is no longer a MiTM) but in other cases, you may not even need to be a MiTM For instance if you don't do any type of verification of the identity. In this case you don't even have to intercept packets. this would apply for instance to the delayed set-up. for instance, suppose that we are using the delayed setup model. I send my id and my locator without any verification and i end up the communication before the verification is performed. then what happens to the state binding the identifier and the locator? if this state is preserved, the correspondent node may use it when establishing communication with the identifier previously used (but not verified). So in order to prevent this, the state should not be used for other communications. OTOH, i really don't see how a MiTM can steal an identity when you are using SIM, for instance. I mean, the identity is the hash of the public key, so the only way to fake the identity would be to be capable of generating the private key... so i don't see how the MiTM could ever do this? > > As a MITM, an attacker can, for example, contaminate DNS cache for > persistent effect. > Well, there is a little difference here... As i mention, in the case that i am considering is the attacker the ones that decides when the state is generated in the victim, so the attacker can choose the moment that it is easier for him to do this. In the DNS case, the attacker has to wait for the DNS query and intercept it. So the attacker doesn't select the moment of the attack, it has to wait the right moment regards, marcelo From owner-multi6@ops.ietf.org Sun Dec 7 17:01:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04979 for ; Sun, 7 Dec 2003 17:01:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AT6tm-0006ju-Ht for multi6-data@psg.com; Sun, 07 Dec 2003 21:57:06 +0000 Received: from [195.43.225.73] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AT6tY-0006jO-UO for multi6@ops.ietf.org; Sun, 07 Dec 2003 21:56:53 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id hB7LudCE015128; Sun, 7 Dec 2003 22:56:42 +0100 (CET) Date: Sun, 7 Dec 2003 22:56:35 +0100 Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] Content-Type: text/plain; charset=ISO-8859-1; format=fixed Mime-Version: 1.0 (Apple Message framework v553) Cc: Dave Crocker , multi6@ops.ietf.org To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3FD2033D.F15984CB@zurich.ibm.com> Message-Id: <39D059AA-2900-11D8-B4C9-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: quoted-printable X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.553) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On l=F6rdag, dec 6, 2003, at 17:26 Europe/Stockholm, Brian E Carpenter=20= wrote: >> Endpoint >> >> refers to "the fundamental entity of and end-end >> communication" [EID]. It is an end-system that = participates >> in an association. Endpoints are distinguished from >> intermediate, infrastructure nodes and from hosts. > > Yes. But this is too generic to be really very useful... and trying to > get more precision always ends in a rat hole. > couldn't we split this into a several definitions. Like Host Describes a physical instance connected to the = internet for=20 the purpose of a certain task, such as workstation, web-server etc. A host can have multiple idenntifiers = and locators Virtual host Several logical implementations of "Host" = running on one=20 or more physical instances. Stack (see NSRG....) Interface The connection point for a host or = virtual host to the=20 Internet. This COULD be through a Stack..xxxxxx Endpoint refers to "the fundamental entity of and = end-end=20 communication" . It is an end-system that participates in an=20 association. The associations can be made between one or = more hosts=20 or virtual hosts. Identifier SHOULD provide a unique identity to be used for = creating=20 associations between Endpoints. Association The exchange or one-way communication between = applications=20 at layer 4 or higher between XXXX . . . . etc. Idea is to try and create a "onion" of definitions. Just go to the=20= right layer. The above is to vague tough... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP9OiFaarNKXTPFCVEQLAxQCfSWOKPPSEtziOtWLOHB7RBEKN/44An22M eTwNU1ghLK9M6fPZDz/fLGg7 =3DZfyd -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Dec 8 03:20:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00089 for ; Mon, 8 Dec 2003 03:20:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATGaU-00082i-1S for multi6-data@psg.com; Mon, 08 Dec 2003 08:17:50 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATGaH-000813-Iw for multi6@ops.ietf.org; Mon, 08 Dec 2003 08:17:37 +0000 Received: (qmail 59336 invoked from network); 8 Dec 2003 08:18:22 -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; 8 Dec 2003 08:18:22 -0000 Message-ID: <3FD43430.9000901@necom830.hpcl.titech.ac.jp> Date: Mon, 08 Dec 2003 17:20:00 +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: additional attack for multi6 threat draft? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; >>>long as the acquired authorization information is valid. >> >>Yes, it is a MITM. > > > in THIS case, is MiTM for a limited period of time. In this case and in other cases, yes. > but in other cases, you may not even need to be a MiTM > For instance if you don't do any type of verification of the identity. An invalid example. On the Internet, RR based verification is MUST, which has nothing to do with M6, which is why I said you need security threat draft on the plain Internet today. > OTOH, i really don't see how a MiTM can steal an identity when you are using > SIM, for instance. I mean, the identity is the hash of the public key, so > the only way to fake the identity would be to be capable of generating the > private key... so i don't see how the MiTM could ever do this? I assume you know well about marrige theory or birthday attack. So, if you are serious on security, hash should be 128 bit long of MD5, at least, though some people insist that MD5 is insecure and it should be 160 bit long of SHA. So, let's assume that the hash is 128 bit long. Note that the hashed value is psuedo random. The direct conclusion is that no one can memorize or type a psuedo random 32 hexadicimal value. That is, no human being identify hosts by 128 bit or longer hash value. So, what are you saying "the only way to fake the identity"? Can't you just say "DNS"? Note also that, on the public Internet, please don't assume that you locally have all the hash values of public keys of hosts you want to communicate. Or, you can assume that you locally have all the public or shared keys of all the hosts. With the shared keys, just use IPsec or something like that. >>As a MITM, an attacker can, for example, contaminate DNS cache for >>persistent effect. > Well, there is a little difference here... > > As i mention, in the case that i am considering is the attacker the ones > that decides when the state is generated in the victim, so the attacker can > choose the moment that it is easier for him to do this. > In the DNS case, the attacker has to wait for the DNS query and intercept > it. So the attacker doesn't select the moment of the attack, it has to wait > the right moment An attacker can control when state is generated in a victim, if the attacker initiate communication with the victim and if the state is not already cached. In the DNS case, state is generated in a victim as a result of DNS query. The DNS is queried when communication is initiated. In the DNS case, an attacker can control when state is generated in a victim, if the attacker initiate communication with the victim and if the state is not already cached. The attacker does select the moment of the attack. Masataka Ohta From owner-multi6@ops.ietf.org Mon Dec 8 03:40:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00892 for ; Mon, 8 Dec 2003 03:40:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATGvc-000ATG-T3 for multi6-data@psg.com; Mon, 08 Dec 2003 08:39:40 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATGuu-000AOb-NY for multi6@ops.ietf.org; Mon, 08 Dec 2003 08:38:57 +0000 Received: (qmail 59394 invoked from network); 8 Dec 2003 08:39:42 -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; 8 Dec 2003 08:39:42 -0000 Message-ID: <3FD43930.1050301@necom830.hpcl.titech.ac.jp> Date: Mon, 08 Dec 2003 17:41:20 +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 , Dave Crocker , multi6@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: <39D059AA-2900-11D8-B4C9-000A9598A184@kurtis.pp.se> In-Reply-To: <39D059AA-2900-11D8-B4C9-000A9598A184@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt; >>Yes. But this is too generic to be really very useful... and trying to >>get more precision always ends in a rat hole. >> > > > couldn't we split this into a several definitions. No, thank you. Why you and Brian (even with WG chair hat on) are disturbbing constructive discussion by insisting on introducing useless terminology? Masataka Ohta From owner-multi6@ops.ietf.org Mon Dec 8 04:15:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01979 for ; Mon, 8 Dec 2003 04:15:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATHSZ-000ENy-HI for multi6-data@psg.com; Mon, 08 Dec 2003 09:13:43 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATHSM-000EMp-Nq for multi6@ops.ietf.org; Mon, 08 Dec 2003 09:13:30 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hB89DiDP028315; Mon, 8 Dec 2003 10:13:46 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3FD43930.1050301@necom830.hpcl.titech.ac.jp> References: <39D059AA-2900-11D8-B4C9-000A9598A184@kurtis.pp.se> <3FD43930.1050301@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] Date: Mon, 8 Dec 2003 10:13:19 +0100 To: Masataka Ohta X-Mailer: Apple Mail (2.606) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 8-dec-03, at 9:41, Masataka Ohta wrote: > Why you and Brian (even with WG chair hat on) are disturbbing > constructive discussion by insisting on introducing useless > terminology? While I don't think that having precise terminology is useless, it's probably better to work on solutions now and solve terminology issues later. If not, we run the risk of very precisely defining things that we're not going to use anyway. From owner-multi6@ops.ietf.org Mon Dec 8 05:59:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05408 for ; Mon, 8 Dec 2003 05:59:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATJ5F-000Pth-Aa for multi6-data@psg.com; Mon, 08 Dec 2003 10:57:45 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATJ51-000PmT-I7 for multi6@ops.ietf.org; Mon, 08 Dec 2003 10:57:31 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A96F6C7F; Mon, 8 Dec 2003 11:57:30 +0100 (CET) Received: from lolo (unknown [163.117.252.58]) by smtp01.uc3m.es (Postfix) with SMTP id 09AEFC7B; Mon, 8 Dec 2003 11:57:29 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" Cc: Subject: RE: additional attack for multi6 threat draft? Date: Mon, 8 Dec 2003 11:50:53 +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: <3FD43430.9000901@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > but in other cases, you may not even need to be a MiTM > > For instance if you don't do any type of verification of the identity. > > An invalid example. > > On the Internet, RR based verification is MUST, Why? because there are some threats that have to be avoided. This one is just one of them. Others are presented in the treats draft. IMHO we have to be aware of all the threats so that we can design a proper solution. this is the goal of the threats draft,i guess. (so that if someone comes up with an invalid solution like the one i have used in the example, you can just point to the threats document and simply say that the solution doesn't prevent threat described in section 7.8 and you don't have to explain the problem all over again, it becomes the author's responsability to show how his solution prevents the threats described) Besides, do you think that RR is a must for verifying locators or identifiers o both? I may agree with RR as a locator verification mechanisms, but i am not so sure about its application as an identifier validation mechanism > which has nothing to do with M6, Is this a general comment or just specific to the threat i am descibing? i mean do you think that all threats described in the threat draft are not M6 specific? > which is why I said you need security threat draft on the plain Internet today. Well, the threats draft attempts to do soemthing similar to this... have you checked section 3 of the draft? Perhaps you could point what additional attacks are possible in the current internet that are not considered there? just to understand your position: do you think we need a threat analysis draft? > > > OTOH, i really don't see how a MiTM can steal an identity when > you are using > > SIM, for instance. I mean, the identity is the hash of the > public key, so > > the only way to fake the identity would be to be capable of > generating the > > private key... so i don't see how the MiTM could ever do this? > > I assume you know well about marrige theory or birthday attack. So, > if you are serious on security, hash should be 128 bit long of MD5, > at least, though some people insist that MD5 is insecure and it > should be 160 bit long of SHA. > > So, let's assume that the hash is 128 bit long. > > Note that the hashed value is psuedo random. > > The direct conclusion is that no one can memorize or type a psuedo > random 32 hexadicimal value. > > That is, no human being identify hosts by 128 bit or longer hash > value. > > So, what are you saying "the only way to fake the identity"? > > Can't you just say "DNS"? > No, because tcp don't use dns names to identify an endpoint involved in a connection, it uses 128 bit long string. This 128 bit long string is the identity of the other endpoint. So if you want to prevent the impersonation of this identity, it seems a good idea to use the (hash) of the public key as the identity. OTOH i see your point. People don't use 128 bit long strings direclty, so the weak point will be the mapping from the DNS to the strong identity. Well this is choice we will have to make, i guess. We can build a strong identity that may become a piece of a more secure architecture (such as sim) or we can just try to find a solution that is just as secure as today internet (like the noid approach) and wait for security improvements in other areas, like in DNS security. > Note also that, on the public Internet, please don't assume that > you locally have all the hash values of public keys of hosts > you want to communicate. Or, you can assume that you locally > have all the public or shared keys of all the hosts. With the > shared keys, just use IPsec or something like that. > > >>As a MITM, an attacker can, for example, contaminate DNS cache for > >>persistent effect. > > > Well, there is a little difference here... > > > > As i mention, in the case that i am considering is the attacker the ones > > that decides when the state is generated in the victim, so the > attacker can > > choose the moment that it is easier for him to do this. > > In the DNS case, the attacker has to wait for the DNS query and > intercept > > it. So the attacker doesn't select the moment of the attack, it > has to wait > > the right moment > > An attacker can control when state is generated in a victim, if > the attacker initiate communication with the victim and if the > state is not already cached. > > In the DNS case, state is generated in a victim as a result of > DNS query. The DNS is queried when communication is initiated. > > In the DNS case, an attacker can control when state is generated > in a victim, if the attacker initiate communication with the > victim and if the state is not already cached. The attacker does > select the moment of the attack. > I fail to see this... The dns query is performed by the initator if the communication. The responding end of the communications does not perform a DNS query (in general), it just sends back packets to the source address and it is not even aware of the name of the initator. So since the attacker is the one initiating the communication, the attacker is the one that performs the dns query. The victim does not perform a DNS query, so how comes that the victims DNS cache is attacked? Regards, marcelo > Masataka Ohta > > > From owner-multi6@ops.ietf.org Mon Dec 8 06:05:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05531 for ; Mon, 8 Dec 2003 06:05:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATJC2-0000lo-AW for multi6-data@psg.com; Mon, 08 Dec 2003 11:04:46 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATJBZ-0000hE-Ep for multi6@ops.ietf.org; Mon, 08 Dec 2003 11:04:17 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A1063C8F; Mon, 8 Dec 2003 12:04:16 +0100 (CET) Received: from lolo (unknown [163.117.252.58]) by smtp01.uc3m.es (Postfix) with SMTP id 143BAC87; Mon, 8 Dec 2003 12:04:15 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Kurt Erik Lindqvist" , "Brian E Carpenter" Cc: "Dave Crocker" , Subject: RE: Terminology [Re: Some Comments on ID/Loc Separation Proposals] Date: Mon, 8 Dec 2003 11:57:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <39D059AA-2900-11D8-B4C9-000A9598A184@kurtis.pp.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi Kurtis, My problem with this is that i fail to see differences between some of the terms that are being defined... For instance stack, endpoint perhaps virtual host... I mean, is there a difference between this two, if so, do we need them both for the multi6 discussion? or we can just pick one? SO i agree we should define as much terms a we feel we need, but we shouldn't define more that we need, at least we should be able to precisely describe the difference between the defined terms IMHO we should just pick one of the above for now and see if it is enough. By now, i just don't care which one, stack, endpoint... Regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Kurt Erik Lindqvist > Enviado el: domingo, 07 de diciembre de 2003 22:57 > Para: Brian E Carpenter > CC: Dave Crocker; multi6@ops.ietf.org > Asunto: Re: Terminology [Re: Some Comments on ID/Loc Separation > Proposals] > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On lördag, dec 6, 2003, at 17:26 Europe/Stockholm, Brian E Carpenter > wrote: > > >> Endpoint > >> > >> refers to "the fundamental entity of and end-end > >> communication" [EID]. It is an end-system that participates > >> in an association. Endpoints are distinguished from > >> intermediate, infrastructure nodes and from hosts. > > > > Yes. But this is too generic to be really very useful... and trying to > > get more precision always ends in a rat hole. > > > > couldn't we split this into a several definitions. Like > > Host Describes a physical instance connected to > the internet for > the purpose of a certain task, such as workstation, web-server etc. > A host can have multiple > idenntifiers and locators > > Virtual host Several logical implementations of "Host" > running on one > or more physical instances. > > Stack (see NSRG....) > > Interface The connection point for a host or > virtual host to the > Internet. This COULD be through a Stack..xxxxxx > > Endpoint refers to "the fundamental entity > of and end-end > communication" . It is an end-system that participates in an > association. The associations can be made between one or > more hosts > or virtual hosts. > > Identifier SHOULD provide a unique identity to be used > for creating > associations between Endpoints. > > Association The exchange or one-way communication > between applications > at layer 4 or higher between XXXX > . > . > . > . > > etc. Idea is to try and create a "onion" of definitions. Just go to the > right layer. The above is to vague tough... > > - - kurtis - > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.2 > > iQA/AwUBP9OiFaarNKXTPFCVEQLAxQCfSWOKPPSEtziOtWLOHB7RBEKN/44An22M > eTwNU1ghLK9M6fPZDz/fLGg7 > =Zfyd > -----END PGP SIGNATURE----- > > From owner-multi6@ops.ietf.org Mon Dec 8 07:03:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06848 for ; Mon, 8 Dec 2003 07:03:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATK4W-0006gg-1n for multi6-data@psg.com; Mon, 08 Dec 2003 12:01:04 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATK4J-0006fW-Ps for multi6@ops.ietf.org; Mon, 08 Dec 2003 12:00:52 +0000 Received: (qmail 59977 invoked from network); 8 Dec 2003 12:01:39 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 8 Dec 2003 12:01:39 -0000 Message-ID: <3FD46882.3030104@necom830.hpcl.titech.ac.jp> Date: Mon, 08 Dec 2003 21:03:14 +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: additional attack for multi6 threat draft? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; >>>but in other cases, you may not even need to be a MiTM >>>For instance if you don't do any type of verification of the identity. >> >>An invalid example. >> >>On the Internet, RR based verification is MUST, > > > Why? Why? Can you name some protocol that does not do this? If you can't, guess "why?". Masataka Ohta From owner-multi6@ops.ietf.org Mon Dec 8 07:24:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07399 for ; Mon, 8 Dec 2003 07:24:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATKQB-000910-7V for multi6-data@psg.com; Mon, 08 Dec 2003 12:23:27 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATKPz-0008yD-1e for multi6@ops.ietf.org; Mon, 08 Dec 2003 12:23:15 +0000 Received: (qmail 60041 invoked from network); 8 Dec 2003 12:24:02 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 8 Dec 2003 12:24:02 -0000 Message-ID: <3FD46DC1.4080400@necom830.hpcl.titech.ac.jp> Date: Mon, 08 Dec 2003 21:25:37 +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: Kurt Erik Lindqvist , Brian E Carpenter , Dave Crocker , multi6@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; > IMHO we should just pick one of the above for now and see if it is enough. > By now, i just don't care which one, stack, endpoint... What's wrong with the "end system", which is the most authentic terminology directly related to the end to end principle? Masataka Ohta From owner-multi6@ops.ietf.org Mon Dec 8 07:28:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07602 for ; Mon, 8 Dec 2003 07:28:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATKTn-0009Po-RG for multi6-data@psg.com; Mon, 08 Dec 2003 12:27:11 +0000 Received: from [204.127.198.39] (helo=rwcrmhc13.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATKTM-0009OT-6X for multi6@ops.ietf.org; Mon, 08 Dec 2003 12:26:44 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (rwcrmhc13) with SMTP id <2003120812264301500bobn7e> (Authid: sdawkins@comcast.net); Mon, 8 Dec 2003 12:26:43 +0000 Message-ID: <005201c3bd86$8b59c790$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <3FD46882.3030104@necom830.hpcl.titech.ac.jp> Subject: Re: additional attack for multi6 threat draft? Date: Mon, 8 Dec 2003 06:26:45 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit OK, this is not a helpful response. If RR based verification really is a MUST, shouldn't that be written down somewhere (more authoritative than the multi6 mailing list), along with at least a basic explanation of why? Can anyone provide a pointer to such a requirement, preferably in an archival document that is at least BCP (and preferably standards-track)? FWIW, the biggest impediment for moving past "the IESG must review and approve all specifications" is the view that working groups don't understand requirements like this one. Having WG participants "guess why" isn't likely to help improve understanding. Spencer ----- Original Message ----- From: "Masataka Ohta" To: Cc: Sent: Monday, December 08, 2003 6:03 AM Subject: Re: additional attack for multi6 threat draft? > >> > >>On the Internet, RR based verification is MUST, > > > > > > Why? > > Why? > > Can you name some protocol that does not do this? > > If you can't, guess "why?". From owner-multi6@ops.ietf.org Mon Dec 8 08:15:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08355 for ; Mon, 8 Dec 2003 08:15:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATLCh-000GVY-15 for multi6-data@psg.com; Mon, 08 Dec 2003 13:13:35 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATLCU-000GT0-Ow for multi6@ops.ietf.org; Mon, 08 Dec 2003 13:13:23 +0000 Received: (qmail 60194 invoked from network); 8 Dec 2003 13:14:11 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 8 Dec 2003 13:14:11 -0000 Message-ID: <3FD47981.4040205@necom830.hpcl.titech.ac.jp> Date: Mon, 08 Dec 2003 22:15:45 +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: Spencer Dawkins CC: multi6@ops.ietf.org Subject: Re: additional attack for multi6 threat draft? References: <3FD46882.3030104@necom830.hpcl.titech.ac.jp> <005201c3bd86$8b59c790$0400a8c0@DFNJGL21> In-Reply-To: <005201c3bd86$8b59c790$0400a8c0@DFNJGL21> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Spencer Dawkins; > If RR based verification really is a MUST, shouldn't that be written > down somewhere (more authoritative than the multi6 mailing list), > along with at least a basic explanation of why? That's what I said necessary several posts ago. > Can anyone provide a pointer to such a requirement, preferably in an > archival document that is at least BCP (and preferably > standards-track)? > > FWIW, the biggest impediment for moving past "the IESG must review and > approve all specifications" is the view that working groups don't > understand requirements like this one. Having WG participants "guess > why" isn't likely to help improve understanding. As IESG is ignorant on producing such a document, don't expect me to overrule it. Masataka Ohta From owner-multi6@ops.ietf.org Mon Dec 8 08:48:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09314 for ; Mon, 8 Dec 2003 08:48:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATLjS-000KPV-2i for multi6-data@psg.com; Mon, 08 Dec 2003 13:47:26 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATLjG-000KOj-5a for multi6@ops.ietf.org; Mon, 08 Dec 2003 13:47:14 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 57F67E17; Mon, 8 Dec 2003 14:47:13 +0100 (CET) Received: from lolo (unknown [163.117.252.53]) by smtp01.uc3m.es (Postfix) with SMTP id D43A3E0B; Mon, 8 Dec 2003 14:47:11 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" Cc: "Kurt Erik Lindqvist" , "Brian E Carpenter" , "Dave Crocker" , Subject: RE: Terminology [Re: Some Comments on ID/Loc Separation Proposals] Date: Mon, 8 Dec 2003 14:40: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) In-Reply-To: <3FD46DC1.4080400@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > What's wrong with the "end system", which is the most authentic > terminology directly related to the end to end principle? i guess there is nothing wrong with it, as long as we define it precisely. could you provide a definition of what do you mean by end system? would it be similar to JNC's endpoint definiton? or NSRG stack definition? I mean, are those three different names for the same concept or do we have a conceptual discrepancy here? As far as i can understand it, we only have one class of objects and we are just discussing about the name to name it. That's why i am fine with any name we choose as long as we define it properly A more important issue would be that we are considering three different objects and that we are arguing which one is the fundamental entity that we should consider in multi6 discussions, but IMHO this is not the case. Regards, marcelo > > Masataka Ohta > From owner-multi6@ops.ietf.org Mon Dec 8 08:56:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09531 for ; Mon, 8 Dec 2003 08:56:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATLra-000Ldy-2d for multi6-data@psg.com; Mon, 08 Dec 2003 13:55:50 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATLrF-000Lb9-52 for multi6@ops.ietf.org; Mon, 08 Dec 2003 13:55:29 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5F487E1E; Mon, 8 Dec 2003 14:55:28 +0100 (CET) Received: from lolo (unknown [163.117.252.53]) by smtp01.uc3m.es (Postfix) with SMTP id 54CD2E1D; Mon, 8 Dec 2003 14:55:27 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" Cc: Subject: RE: additional attack for multi6 threat draft? Date: Mon, 8 Dec 2003 14:48:51 +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: <3FD46882.3030104@necom830.hpcl.titech.ac.jp> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Why? > > Why? > > Can you name some protocol that does not do this? Take mip and remove the rr check. You are supposedly talking to the HoA but you are sending packets to the CoA, so you don't have a RR check of the address that you are supposed to be talking to i.e. the HoA Again, RR is fine to verify locators but it is not so great to verify identifiers. In multi6 where we may need redirection, you cannot assume that RR will be available to verify identities Regards, marcelo > > If you can't, guess "why?". > > Masataka Ohta > > From owner-multi6@ops.ietf.org Mon Dec 8 08:57:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09570 for ; Mon, 8 Dec 2003 08:57:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATLs1-000LfJ-4D for multi6-data@psg.com; Mon, 08 Dec 2003 13:56:17 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATLrG-000LbH-Ky for multi6@ops.ietf.org; Mon, 08 Dec 2003 13:55:30 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D6E98E1F; Mon, 8 Dec 2003 14:55:29 +0100 (CET) Received: from lolo (unknown [163.117.252.53]) by smtp01.uc3m.es (Postfix) with SMTP id AC88FE1D; Mon, 8 Dec 2003 14:55:28 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Spencer Dawkins" , Subject: RE: additional attack for multi6 threat draft? Date: Mon, 8 Dec 2003 14:48:53 +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: <005201c3bd86$8b59c790$0400a8c0@DFNJGL21> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Spencer, My interpretation of Masataka comment is the following When you communicate with another host, you exchange packets with it, so basically you are performing RR check since you are able to actually exchange packets. Is this what you meant Masataka? The problem in multi6 is that since we may need to change the locator during the lifetime of an established asociation, we may still think that we are communication with the initial locator while in reallity packets are being diverted to a new alternative address. In this case, the implicit RR check is being performed to new locator and not to the initial locator that the initiating entities think they are communicating to. So IMHO RR is good to verify locators but not so good to verify identities Hope this makes some sense regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Spencer Dawkins > Enviado el: lunes, 08 de diciembre de 2003 13:27 > Para: multi6@ops.ietf.org > Asunto: Re: additional attack for multi6 threat draft? > > > OK, this is not a helpful response. > > If RR based verification really is a MUST, shouldn't that be written > down somewhere (more authoritative than the multi6 mailing list), > along with at least a basic explanation of why? > > Can anyone provide a pointer to such a requirement, preferably in an > archival document that is at least BCP (and preferably > standards-track)? > > FWIW, the biggest impediment for moving past "the IESG must review and > approve all specifications" is the view that working groups don't > understand requirements like this one. Having WG participants "guess > why" isn't likely to help improve understanding. > > Spencer > > ----- Original Message ----- > From: "Masataka Ohta" > To: > Cc: > Sent: Monday, December 08, 2003 6:03 AM > Subject: Re: additional attack for multi6 threat draft? > > >> > > >>On the Internet, RR based verification is MUST, > > > > > > > > > Why? > > > > Why? > > > > Can you name some protocol that does not do this? > > > > If you can't, guess "why?". > > From owner-multi6@ops.ietf.org Mon Dec 8 10:40:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14933 for ; Mon, 8 Dec 2003 10:40:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATNSA-0008fU-Pe for multi6-data@psg.com; Mon, 08 Dec 2003 15:37:42 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATNRw-0008ef-T1 for multi6@ops.ietf.org; Mon, 08 Dec 2003 15:37:29 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id hB8FbECE026841; Mon, 8 Dec 2003 16:37:14 +0100 (CET) Date: Mon, 8 Dec 2003 16:37:10 +0100 Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v553) Cc: "Brian E Carpenter" , "Dave Crocker" , To: From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <637CEC9E-2994-11D8-9318-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.553) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > My problem with this is that i fail to see differences between some of > the > terms that are being defined... > For instance stack, endpoint perhaps virtual host... > > I mean, is there a difference between this two, if so, do we need them > both > for the multi6 discussion? or we can just pick one? > > SO i agree we should define as much terms a we feel we need, but we > shouldn't define more that we need, at least we should be able to > precisely > describe the difference between the defined terms I agree with Iljitsch remark that we should focus on the solutions, rather than the terminology. At the same time, when there are ambiguities that makes us go into spin for a week, I think we do gain from having a clear set of terms. Which ones we need and don't need will very much depend on which solutions we are looking at. I didn't mean to cast the proposal in stone. It was meant as an example. But I do think that we need an authoritative list of terminology. But we could define that as we go along and needs arises. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP9SaqKarNKXTPFCVEQJNwgCgrcirz0jYA+PBggGp/5tVFYVIWUUAmwb+ Zix9oZiUab2PXcMzgU0TLvBz =UIBk -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Dec 8 14:59:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27176 for ; Mon, 8 Dec 2003 14:59:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATRUc-000FRH-Lz for multi6-data@psg.com; Mon, 08 Dec 2003 19:56:30 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATRUQ-000FPb-Gb for multi6@ops.ietf.org; Mon, 08 Dec 2003 19:56:19 +0000 Received: (qmail 61735 invoked from network); 8 Dec 2003 19:57:11 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 8 Dec 2003 19:57:11 -0000 Message-ID: <3FD4D7F1.8040705@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Dec 2003 04:58: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: mbagnulo@ing.uc3m.es CC: Kurt Erik Lindqvist , Brian E Carpenter , Dave Crocker , multi6@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; >>What's wrong with the "end system", which is the most authentic >>terminology directly related to the end to end principle? > > > i guess there is nothing wrong with it, as long as we define it precisely. It is a word appears in RFC1958, editor of which is Brian. > could you provide a definition of what do you mean by end system? would it > be similar to JNC's endpoint definiton? or NSRG stack definition? As I searched reference of the RFC, "end point" seems to be an alternative wording of "end system" that if JNC is saying "endpoint" with the difinition of Saltzer's paper, that is fine. Forget NSRG. Masataka Ohta From owner-multi6@ops.ietf.org Mon Dec 8 15:12:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28447 for ; Mon, 8 Dec 2003 15:12:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATRit-000HA3-7I for multi6-data@psg.com; Mon, 08 Dec 2003 20:11:15 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATRig-000H93-0g for multi6@ops.ietf.org; Mon, 08 Dec 2003 20:11:02 +0000 Received: (qmail 61802 invoked from network); 8 Dec 2003 20:11:56 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 8 Dec 2003 20:11:56 -0000 Message-ID: <3FD4DB65.9000902@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Dec 2003 05:13:25 +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: additional attack for multi6 threat draft? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; >>>Why? >> >>Why? >> >>Can you name some protocol that does not do this? > Take mip and remove the rr check. > You are supposedly talking to the HoA but you are sending packets to the > CoA, so you don't have a RR check of the address that you are supposed to be > talking to i.e. the HoA You are talking about triangle elimination, which, as I mentioned, is a cause of new form of redirection attack. However, it is purely a mobility issue having nothing to do with multihoming. A CN and a MN can use all the complex security mechanism to locate and identify each other. However, it does not prevent MN redirection of traffic of CN to a DOS victim. The victim can be protected from DoS, if 8+8 is used, though the network around the victim still suffer. > Again, RR is fine to verify locators but it is not so great to verify > identifiers. RR check involves cookie exchange, which is to verify the identity. > In multi6 where we may need redirection, you cannot assume that RR will be > available to verify identities Cookie is our friend. Masataka Ohta From owner-multi6@ops.ietf.org Mon Dec 8 19:05:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14471 for ; Mon, 8 Dec 2003 19:05:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATVHG-000LEG-Vr for multi6-data@psg.com; Mon, 08 Dec 2003 23:58:58 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATVGv-000L4P-Gi for multi6@ops.ietf.org; Mon, 08 Dec 2003 23:58:37 +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 hB923GOt099505; Mon, 8 Dec 2003 18:03:16 -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 hB8NvpYB026547; Mon, 8 Dec 2003 15:57:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: delayed multihoming/mobility set-up Date: Mon, 8 Dec 2003 15:57:51 -0800 Message-ID: Thread-Topic: delayed multihoming/mobility set-up Thread-Index: AcO3zA70Fd+OkP+2QWGssaNGsl8LawAYLgzAAW50ZhA= From: "Tony Li" To: "Christian Huitema" , "Masataka Ohta" Cc: "Iljitsch van Beijnum" , "Multi6 Mailing List" X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Catching up... Christian, I would agree with your timeline but would suggest one small tweak: Once the "set of equivalent addresses" has been exchanged, then for implementation reasons, it makes some sense to locate an alternate set of working addresses BEFORE the transport event happens. This is necessary because this is an O(N^2) problem and you don't want to have to solve it in real time. Of course, some intelligence in the host to choose "better" addresses could make for some implementation differentiation too. Tony | -----Original Message----- | From: Christian Huitema [mailto:huitema@windows.microsoft.com]=20 | Sent: Monday, December 01, 2003 9:19 AM | To: Masataka Ohta; dcrocker@brandenburg.com | Cc: Iljitsch van Beijnum; Multi6 Mailing List | Subject: RE: delayed multihoming/mobility set-up | =20 | =20 | > > IvB> The reason that BGP | > > IvB> rerouting can take so long is that the RFC mandates=20 | a 90 second | > hold | > > IvB> time, | >=20 | > And a 90 second hold time is already too long. | =20 | ... which is why I am convinced that the solution to=20 | preserving existing | communication is closest to "transport protocols" than "routing | protocols". The time scale of transport protocols is the=20 | RTT; the time | scale of routing protocols is the minute. If we wait for a=20 | routing event | to be somehow signaled to the transport stack, the connection will be | gone. The natural solution is to use a transport event, e.g. a | retransmission timer. This event can trigger an end-to-end=20 | "connection | rehoming" exchange. | =20 | My preferred time-line would be: | =20 | 1) Start a communication using one of the available pairs of src/dest | addresses. | 2) If the communication is determined to be worth it (i.e. last long | enough), engage in "multi-homing signaling" to obtain a "set of | equivalent addresses" | 3) On a transport event such as retransmission time-out,=20 | probe alternate | pairs of src/dest addresses, and pick a "better one" if available. | =20 | I would note that a lot of the communication we have today=20 | do not meet | the "worth it" requirement. The top applications in the=20 | Internet today | are web pages, which mostly consist of a large number of very short | exchanges, and p2p file sharing, which includes its own application | level tools to deal with multi-homing.=20 | =20 | -- Christian Huitema | =20 | =20 From owner-multi6@ops.ietf.org Tue Dec 9 04:28:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19376 for ; Tue, 9 Dec 2003 04:28:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATe7V-000CfH-Ca for multi6-data@psg.com; Tue, 09 Dec 2003 09:25:29 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATe76-000Cch-VG for multi6@ops.ietf.org; Tue, 09 Dec 2003 09:25:05 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB99P3RJ102600 for ; Tue, 9 Dec 2003 09:25:03 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB99P2UU215484 for ; Tue, 9 Dec 2003 10:25:02 +0100 Received: from zurich.ibm.com ([9.145.175.184]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA22552 for ; Tue, 9 Dec 2003 10:24:59 +0100 Message-ID: <3FD594B6.FC368986@zurich.ibm.com> Date: Tue, 09 Dec 2003 10:24: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: multi6@ops.ietf.org Subject: Reminder re multi6 drafts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 From owner-multi6@ops.ietf.org Tue Dec 9 04:28:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19395 for ; Tue, 9 Dec 2003 04:28:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATeAA-000Cw4-Nw for multi6-data@psg.com; Tue, 09 Dec 2003 09:28:14 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATe9y-000Cun-AP for multi6@ops.ietf.org; Tue, 09 Dec 2003 09:28:02 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB99RLn0103030; Tue, 9 Dec 2003 09:27:22 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB99RJUU182592; Tue, 9 Dec 2003 10:27:19 +0100 Received: from zurich.ibm.com ([9.145.175.184]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA31796; Tue, 9 Dec 2003 10:27:16 +0100 Message-ID: <3FD5953F.26BE3376@zurich.ibm.com> Date: Tue, 09 Dec 2003 10:26: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: Masataka Ohta CC: Spencer Dawkins , Multi6 Mailing List Subject: Re: delayed multihoming/mobility set-up References: <2AFFEB20-24B0-11D8-A441-000A95CD987A@muada.com> <00c001c3b8d2$23a22e20$0400a8c0@DFNJGL21> <3FD1FB9A.FCDA0A3F@zurich.ibm.com> <3FD25CD7.2070101@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ohta-san, we decided to start with the "additionl goals" draft that Eliot is writing, and to examine the various proposals for their common architectural features. This does not meaning immediately writing a draft. Brian Masataka Ohta wrote: > > Brian; > > > One of our current objectives is to start architectural breakdown > > and analysis. > > Huh? At Minneapolis, you denied my proposal to have architectural > document, because most of us can 't do it. > > Why and how have you changed your mind? > > Masataka Ohta -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-multi6@ops.ietf.org Tue Dec 9 04:40:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19639 for ; Tue, 9 Dec 2003 04:40:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATeLC-000EGS-35 for multi6-data@psg.com; Tue, 09 Dec 2003 09:39:38 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATeKz-000EE4-10 for multi6@ops.ietf.org; Tue, 09 Dec 2003 09:39:25 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB99d9Gs106514; Tue, 9 Dec 2003 09:39:09 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB99d5El150734; Tue, 9 Dec 2003 10:39:05 +0100 Received: from zurich.ibm.com ([9.145.175.184]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA43938; Tue, 9 Dec 2003 10:39:02 +0100 Message-ID: <3FD59802.AAF3FA47@zurich.ibm.com> Date: Tue, 09 Dec 2003 10:38:10 +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: Kurt Erik Lindqvist CC: mbagnulo@ing.uc3m.es, Dave Crocker , multi6@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: <637CEC9E-2994-11D8-9318-000A9598A184@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > My problem with this is that i fail to see differences between some of > > the > > terms that are being defined... > > For instance stack, endpoint perhaps virtual host... > > > > I mean, is there a difference between this two, if so, do we need them > > both > > for the multi6 discussion? or we can just pick one? > > > > SO i agree we should define as much terms a we feel we need, but we > > shouldn't define more that we need, at least we should be able to > > precisely > > describe the difference between the defined terms > > I agree with Iljitsch remark that we should focus on the solutions, > rather than the terminology. At the same time, when there are > ambiguities that makes us go into spin for a week, I think we do gain > from having a clear set of terms. Which ones we need and don't need > will very much depend on which solutions we are looking at. I didn't > mean to cast the proposal in stone. It was meant as an example. But I > do think that we need an authoritative list of terminology. But we > could define that as we go along and needs arises. Agreed. As we've seen, attempts to define "end point" go into a rathole. But in practical terms it *does* matter whether we are talking about multihoming affecting one physical interface, a set of interfaces on one machine, a set of interfaces on a cluster of machines, or something else. Brian From owner-multi6@ops.ietf.org Tue Dec 9 04:42:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19695 for ; Tue, 9 Dec 2003 04:42:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATeNW-000Ehd-K0 for multi6-data@psg.com; Tue, 09 Dec 2003 09:42:02 +0000 Received: from [195.212.29.156] (helo=mtagate7.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATeNJ-000EgR-ED for multi6@ops.ietf.org; Tue, 09 Dec 2003 09:41:49 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB99fHwj042852; Tue, 9 Dec 2003 09:41:17 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB99fHUU283328; Tue, 9 Dec 2003 10:41:17 +0100 Received: from zurich.ibm.com ([9.145.175.184]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA34154; Tue, 9 Dec 2003 10:41:14 +0100 Message-ID: <3FD59886.491A67E9@zurich.ibm.com> Date: Tue, 09 Dec 2003 10:40: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: mbagnulo@ing.uc3m.es CC: Masataka Ohta , multi6@ops.ietf.org Subject: Re: additional attack for multi6 threat draft? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Gentlemen, I think this thread has reached the end of its useful life. When Erik updates the threats draft, I am sure he will know whether to add this point to it. Thanks Brian co-chair hat on marcelo bagnulo wrote: > > > > Why? > > > > Why? > > > > Can you name some protocol that does not do this? > > Take mip and remove the rr check. > You are supposedly talking to the HoA but you are sending packets to the > CoA, so you don't have a RR check of the address that you are supposed to be > talking to i.e. the HoA > > Again, RR is fine to verify locators but it is not so great to verify > identifiers. > > In multi6 where we may need redirection, you cannot assume that RR will be > available to verify identities > > Regards, marcelo > > > > > If you can't, guess "why?". > > > > Masataka Ohta > > > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-multi6@ops.ietf.org Tue Dec 9 05:05:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20234 for ; Tue, 9 Dec 2003 05:05:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATejB-000Hi2-E6 for multi6-data@psg.com; Tue, 09 Dec 2003 10:04:25 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATeiy-000HhO-OL for multi6@ops.ietf.org; Tue, 09 Dec 2003 10:04:13 +0000 Received: (qmail 64328 invoked from network); 9 Dec 2003 10:05:17 -0000 Received: from denta.hongo.wide.ad.jp (HELO necom830.hpcl.titech.ac.jp) (203.178.139.78) by necom830.hpcl.titech.ac.jp with SMTP; 9 Dec 2003 10:05:17 -0000 Message-ID: <3FD59EAD.3070706@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Dec 2003 19:06:37 +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@ops.ietf.org Subject: Re: additional attack for multi6 threat draft? References: <3FD59886.491A67E9@zurich.ibm.com> In-Reply-To: <3FD59886.491A67E9@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > Gentlemen, I think this thread has reached the end of its > useful life. When Erik updates the threats draft, I am sure he > will know whether to add this point to it. Erik? Huh? I, not Erik, find the thread is still useful to write a threats draft. > Brian > co-chair hat on Are you sure? Masataka Ohta From owner-multi6@ops.ietf.org Tue Dec 9 05:09:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20365 for ; Tue, 9 Dec 2003 05:09:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATenZ-000INK-Oi for multi6-data@psg.com; Tue, 09 Dec 2003 10:08:57 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATenN-000IMn-MO for multi6@ops.ietf.org; Tue, 09 Dec 2003 10:08:46 +0000 Received: (qmail 64338 invoked from network); 9 Dec 2003 10:09:50 -0000 Received: from denta.hongo.wide.ad.jp (HELO necom830.hpcl.titech.ac.jp) (203.178.139.78) by necom830.hpcl.titech.ac.jp with SMTP; 9 Dec 2003 10:09:50 -0000 Message-ID: <3FD59FBF.8080807@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Dec 2003 19:11: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: Kurt Erik Lindqvist , mbagnulo@ing.uc3m.es, Dave Crocker , multi6@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: <637CEC9E-2994-11D8-9318-000A9598A184@kurtis.pp.se> <3FD59802.AAF3FA47@zurich.ibm.com> In-Reply-To: <3FD59802.AAF3FA47@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > But in practical terms it *does* matter whether we are talking about > multihoming affecting one physical interface, a set of interfaces on > one machine, a set of interfaces on a cluster of machines, or something > else. It does NOT matter. Physical interface is not a meaningful entity. As I and Iljitsch discussed, a cluster of machines virtually acting as a single host can be treated as a single host. Masataka Ohta From owner-multi6@ops.ietf.org Tue Dec 9 05:39:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21464 for ; Tue, 9 Dec 2003 05:39:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATfEr-000LSp-Py for multi6-data@psg.com; Tue, 09 Dec 2003 10:37:09 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATfE7-000LLh-JU for multi6@ops.ietf.org; Tue, 09 Dec 2003 10:36:23 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB9AaCHf097410; Tue, 9 Dec 2003 10:36:12 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB9AaBUU242224; Tue, 9 Dec 2003 11:36:11 +0100 Received: from zurich.ibm.com ([9.145.244.221]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA47308; Tue, 9 Dec 2003 11:36:08 +0100 Message-ID: <3FD5A564.969AE2FD@zurich.ibm.com> Date: Tue, 09 Dec 2003 11:35:16 +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: Kurt Erik Lindqvist , mbagnulo@ing.uc3m.es, Dave Crocker , multi6@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: <637CEC9E-2994-11D8-9318-000A9598A184@kurtis.pp.se> <3FD59802.AAF3FA47@zurich.ibm.com> <3FD59FBF.8080807@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ohta-san, In practical terms it matters very much. If the end point is distributed, multihoming it is a much more complex operation (assuming you want sessions to survive a multihoming event). Perhaps if you speak to some people actually implementing virtualized server pools this would be clearer to you. Brian Masataka Ohta wrote: > > Brian; > > > But in practical terms it *does* matter whether we are talking about > > multihoming affecting one physical interface, a set of interfaces on > > one machine, a set of interfaces on a cluster of machines, or something > > else. > > It does NOT matter. > > Physical interface is not a meaningful entity. > > As I and Iljitsch discussed, a cluster of machines virtually acting > as a single host can be treated as a single host. > > Masataka Ohta -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-multi6@ops.ietf.org Tue Dec 9 05:46:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21568 for ; Tue, 9 Dec 2003 05:46:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATfN1-000MUc-Ie for multi6-data@psg.com; Tue, 09 Dec 2003 10:45:35 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATfMp-000MSi-GA for multi6@ops.ietf.org; Tue, 09 Dec 2003 10:45:24 +0000 Received: (qmail 64477 invoked from network); 9 Dec 2003 10:46:28 -0000 Received: from denta.hongo.wide.ad.jp (HELO necom830.hpcl.titech.ac.jp) (203.178.139.78) by necom830.hpcl.titech.ac.jp with SMTP; 9 Dec 2003 10:46:28 -0000 Message-ID: <3FD5A855.5070405@necom830.hpcl.titech.ac.jp> Date: Tue, 09 Dec 2003 19:47: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: Brian E Carpenter CC: Kurt Erik Lindqvist , mbagnulo@ing.uc3m.es, Dave Crocker , multi6@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: <637CEC9E-2994-11D8-9318-000A9598A184@kurtis.pp.se> <3FD59802.AAF3FA47@zurich.ibm.com> <3FD59FBF.8080807@necom830.hpcl.titech.ac.jp> <3FD5A564.969AE2FD@zurich.ibm.com> In-Reply-To: <3FD5A564.969AE2FD@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > In practical terms it matters very much. If the end point is distributed, > multihoming it is a much more complex operation (assuming you want sessions > to survive a multihoming event). Perhaps if you speak to some people actually > implementing virtualized server pools this would be clearer to you. Practically, the servers in a pool is concentrated, not distributed, which means all the members shares external connectivity. Or, if you are talking about servers distributed over multiple sites, it is complex not because of M6 but because of involving multiple sites. Let's make a site or something members of which shares fate of connectivity multihomed. Masataka Ohta From owner-multi6@ops.ietf.org Tue Dec 9 07:25:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23807 for ; Tue, 9 Dec 2003 07:25:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATgqu-0007SD-8z for multi6-data@psg.com; Tue, 09 Dec 2003 12:20:32 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATgqh-0007Qo-On for multi6@ops.ietf.org; Tue, 09 Dec 2003 12:20:19 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B6DC9A7A; Tue, 9 Dec 2003 13:20:18 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.227]) by smtp01.uc3m.es (Postfix) with SMTP id 8F660AB9; Tue, 9 Dec 2003 13:20:18 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Masataka Ohta" Cc: "Kurt Erik Lindqvist" , "Brian E Carpenter" , "Dave Crocker" , Subject: RE: Terminology [Re: Some Comments on ID/Loc Separation Proposals] Date: Tue, 9 Dec 2003 13:13:41 +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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3FD4D7F1.8040705@necom830.hpcl.titech.ac.jp> X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > i guess there is nothing wrong with it, as long as we define it > precisely. Id oes appears in RFC1958, but i couldn't find any precise definition of what an end-system is in there > > It is a word appears in RFC1958, editor of which is Brian. > > > could you provide a definition of what do you mean by end > system? would it > > be similar to JNC's endpoint definiton? or NSRG stack definition? > > As I searched reference of the RFC, "end point" seems to be an > alternative wording of "end system" that if JNC is saying "endpoint" > with the difinition of Saltzer's paper, that is fine. Sorry but i couldn't find any definition of an end-system in Saltzer paper "END-TO-END ARGUMENTS IN SYSTEM DESIGN ", actually i couldn't even find the end-system expression on the paper What i did found is the end-point expression a couple of times: Like in: "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. " or in "Thus the end-to-end argument is not an absolute rule, but rather a guideline that helps in application and protocol design analysis; one must use some care to identify the end points to which the argument should be applied." However i couldn't find any precise definition about endpoint, so i reffer to JNC's endpoint docuemnte where several really nice definition of endpoint can be found. The definition are (so you don't have to look for it) "To recap, however, an "endpoint" is, in order of increasing formality: - one participant of an end-end communication - the fundamental agent of end-end communication - the entity which is performing a reliable communication on an end-end basis - a fatesharing region - a boundary drawn around a set of state and/or computations such that it lives or dies as a unit" So, so far i like using endpoint because we have a definition for it and IMHO it suit our needs. > > Forget NSRG. Why? stack is also well defined in the nsrg report as: ". A stack is defined as one participant or the process on one side of an end-to-end communication. " So, IMHO we have endpoint and stack well defined I haven't been able to find a definition for end-system, so i would adhere to your own argument and propose that we just use an existent already defined term and not try to introduce a new definition for a term here. However, i still don't understand the difference between an endpoint and a stack (especially since the definition of stack is the same as the first definition of an endpoint...) Regards, marcelo > > Masataka Ohta > > From owner-multi6@ops.ietf.org Tue Dec 9 09:04:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26186 for ; Tue, 9 Dec 2003 09:04:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATiQy-000JKN-Oa for multi6-data@psg.com; Tue, 09 Dec 2003 14:01:52 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATiQd-000JE9-6Z for multi6@ops.ietf.org; Tue, 09 Dec 2003 14:01:31 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB9E0vn0092532; Tue, 9 Dec 2003 14:00:58 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB9E0uUU266914; Tue, 9 Dec 2003 15:00:57 +0100 Received: from zurich.ibm.com ([9.145.247.218]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA22878; Tue, 9 Dec 2003 15:00:54 +0100 Message-ID: <3FD5D561.B0078703@zurich.ibm.com> Date: Tue, 09 Dec 2003 15:00: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: mbagnulo@ing.uc3m.es, multi6@ops.ietf.org Subject: Re: additional attack for multi6 threat draft? References: <3FD59886.491A67E9@zurich.ibm.com> <3FD59EAD.3070706@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark is the editor of the threats draft. draft-nordmark-multi6-threats-00.txt Yes, I am sure I am co-chair of this WG. Brian Masataka Ohta wrote: > > Brian; > > > Gentlemen, I think this thread has reached the end of its > > useful life. When Erik updates the threats draft, I am sure he > > will know whether to add this point to it. > > Erik? > > Huh? > > I, not Erik, find the thread is still useful to write a threats > draft. > > > Brian > > co-chair hat on > > Are you sure? > > Masataka Ohta -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-multi6@ops.ietf.org Tue Dec 9 09:04:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26208 for ; Tue, 9 Dec 2003 09:04:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATiSr-000JbE-LV for multi6-data@psg.com; Tue, 09 Dec 2003 14:03:49 +0000 Received: from [195.212.29.156] (helo=mtagate7.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATiSd-000JVK-Iz for multi6@ops.ietf.org; Tue, 09 Dec 2003 14:03:35 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB9E3Gwj080438; Tue, 9 Dec 2003 14:03:16 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB9E3GEl271130; Tue, 9 Dec 2003 15:03:16 +0100 Received: from zurich.ibm.com ([9.145.247.218]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA44692; Tue, 9 Dec 2003 15:03:14 +0100 Message-ID: <3FD5D5ED.55ACA737@zurich.ibm.com> Date: Tue, 09 Dec 2003 15:02:21 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Masataka Ohta , Kurt Erik Lindqvist , Dave Crocker , multi6@ops.ietf.org Subject: This conversation is over [Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals]] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It's my fault for mentioning the need to document our terminology, but this thread serves no useful purpose for multi6 that I can see. I suggest that those interested now continue it off-list. Thanks Brian marcelo bagnulo wrote: > > > > i guess there is nothing wrong with it, as long as we define it > > precisely. > > Id oes appears in RFC1958, but i couldn't find any precise definition of > what an end-system is in there > > > > > It is a word appears in RFC1958, editor of which is Brian. > > > > > could you provide a definition of what do you mean by end > > system? would it > > > be similar to JNC's endpoint definiton? or NSRG stack definition? > > > > As I searched reference of the RFC, "end point" seems to be an > > alternative wording of "end system" that if JNC is saying "endpoint" > > with the difinition of Saltzer's paper, that is fine. > > Sorry but i couldn't find any definition of an end-system in Saltzer paper > "END-TO-END ARGUMENTS IN SYSTEM DESIGN > ", actually i couldn't even find the end-system expression on the paper > What i did found is the end-point expression a couple of times: > > Like in: > "The function in question can completely and correctly be implemented only > with the knowledge and help of the application standing at the end points of > the communication system. " > or in > "Thus the end-to-end argument is not an absolute rule, but rather a > guideline that helps in application and protocol design analysis; one must > use some care to identify the end points to which the argument should be > applied." > > However i couldn't find any precise definition about endpoint, so i reffer > to JNC's endpoint docuemnte where several really nice definition of endpoint > can be found. > > The definition are (so you don't have to look for it) > > "To recap, however, an "endpoint" is, in order of increasing > formality: > > - one participant of an end-end communication > - the fundamental agent of end-end communication > - the entity which is performing a reliable communication on an > end-end basis > > - a fatesharing region > - a boundary drawn around a set of state and/or computations such > that it lives or dies as a unit" > > So, so far i like using endpoint because we have a definition for it and > IMHO it suit our needs. > > > > > Forget NSRG. > > Why? > > stack is also well defined in the nsrg report as: ". A stack is defined as > one participant or the process on one side of an end-to-end communication. > " > > So, IMHO we have endpoint and stack well defined > I haven't been able to find a definition for end-system, so i would adhere > to your own argument and propose that we just use an existent already > defined term and not try to introduce a new definition for a term here. > > However, i still don't understand the difference between an endpoint and a > stack (especially since the definition of stack is the same as the first > definition of an endpoint...) > > Regards, marcelo > > > > > Masataka Ohta > > > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-multi6@ops.ietf.org Tue Dec 9 09:41:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27064 for ; Tue, 9 Dec 2003 09:41:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATj22-000NeG-7p for multi6-data@psg.com; Tue, 09 Dec 2003 14:40:10 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATj1g-000NYc-BI for multi6@ops.ietf.org; Tue, 09 Dec 2003 14:39:48 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hB9Ee9DP047959; Tue, 9 Dec 2003 15:40:09 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3FD5A564.969AE2FD@zurich.ibm.com> References: <637CEC9E-2994-11D8-9318-000A9598A184@kurtis.pp.se> <3FD59802.AAF3FA47@zurich.ibm.com> <3FD59FBF.8080807@necom830.hpcl.titech.ac.jp> <3FD5A564.969AE2FD@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <87AD82EC-2A55-11D8-9581-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 Mailing List From: Iljitsch van Beijnum Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] Date: Tue, 9 Dec 2003 15:39:44 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.606) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9-dec-03, at 11:35, Brian E Carpenter wrote: > In practical terms it matters very much. If the end point is > distributed, > multihoming it is a much more complex operation (assuming you want > sessions > to survive a multihoming event). Perhaps if you speak to some people > actually implementing virtualized server pools this would be clearer > to you. This depends where we put the demarcation point. I think a place that puts multihoming functionality on one side, and host virtuality on the other would be a very good choice. In other words: this is something for the cluster software implementers to worry about. From owner-multi6@ops.ietf.org Tue Dec 9 10:23:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29880 for ; Tue, 9 Dec 2003 10:23:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATjfD-0002a3-JS for multi6-data@psg.com; Tue, 09 Dec 2003 15:20:39 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATjf0-0002Yc-II for multi6@ops.ietf.org; Tue, 09 Dec 2003 15:20:27 +0000 Received: (qmail 65273 invoked from network); 9 Dec 2003 15:21:34 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 9 Dec 2003 15:21:34 -0000 Message-ID: <3FD5E8CA.6040606@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Dec 2003 00:22:50 +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@ops.ietf.org Subject: Re: additional attack for multi6 threat draft? References: <3FD59886.491A67E9@zurich.ibm.com> <3FD59EAD.3070706@necom830.hpcl.titech.ac.jp> <3FD5D561.B0078703@zurich.ibm.com> In-Reply-To: <3FD5D561.B0078703@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > Erik Nordmark is the editor of the threats draft. > draft-nordmark-multi6-threats-00.txt Erik is an editor of a threets draft. That is, Erik may write his own draft and I or someon else may write another, which is the agreement of the last meeting. > Yes, I am sure I am co-chair of this WG. I am not. Or, are you sure that draft-nordmark-multi6-threats-00.txt is a WG draft? Masataka Ohta From owner-multi6@ops.ietf.org Tue Dec 9 10:30:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00234 for ; Tue, 9 Dec 2003 10:30:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATjnI-0003PA-Sx for multi6-data@psg.com; Tue, 09 Dec 2003 15:29:00 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATjn6-0003Oa-Hp for multi6@ops.ietf.org; Tue, 09 Dec 2003 15:28:48 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 33F9C872D6; Tue, 9 Dec 2003 10:28:48 -0500 (EST) To: multi6@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] Cc: jnc@mercury.lcs.mit.edu Message-Id: <20031209152848.33F9C872D6@mercury.lcs.mit.edu> Date: Tue, 9 Dec 2003 10:28:48 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "marcelo bagnulo" > could you provide a definition of what do you mean by end system? would > it be similar to JNC's endpoint definiton? or NSRG stack definition? > I mean, are those three different names for the same concept or do we > have a conceptual discrepancy here? As far as i can understand it, we > only have one class of objects and we are just discussing about the > name to name it. I think that's basically the case. See, I don't recall seeing any cases of confusion caused by different understandings of what is meant by use of the term "endpoint" or "stack" (or whatever). So my sense is that although we don't necessarily have an agreed-upon precise definition of what one is (and I don't have the energy to explain now why "a fate-sharing region" is the way to go - there is a very powerful argument as to why but I'm too groggy to reproduce it right now), we do have a (roughly common) understanding of what it is were're talking about. This is rather different from the case of the term "identifier", where clearly there have been people with very different assumptions as to what that term meant. So I would therefore suggest (based on prior bitter experience with the word "address") that any documents we create use some *new* term, and *not* "identifier", for whatever name we come up with that identifies the end-things (without giving their location). Noel PS: As to which name to prefer for end-things, I would suggest we not use "stack", since that has been demonstrated to be a poential source of confusion with "dual-stack" hosts. From owner-multi6@ops.ietf.org Tue Dec 9 10:31:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00278 for ; Tue, 9 Dec 2003 10:31:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATjoO-0003cP-Ta for multi6-data@psg.com; Tue, 09 Dec 2003 15:30:08 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATjo4-0003Xo-K1 for multi6@ops.ietf.org; Tue, 09 Dec 2003 15:29:48 +0000 Received: (qmail 65309 invoked from network); 9 Dec 2003 15:30:57 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 9 Dec 2003 15:30:57 -0000 Message-ID: <3FD5EAFC.3070707@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Dec 2003 00:32: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: mbagnulo@ing.uc3m.es CC: Kurt Erik Lindqvist , Brian E Carpenter , Dave Crocker , multi6@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo; >>>i guess there is nothing wrong with it, as long as we define it >> >>precisely. > Id oes appears in RFC1958, but i couldn't find any precise definition of > what an end-system is in there It depends on how precisely you understand RFC1958. It is a concise draft. >>It is a word appears in RFC1958, editor of which is Brian. > Sorry but i couldn't find any definition of an end-system in Saltzer paper As I wrotge, it's in the RFC. > However i couldn't find any precise definition about endpoint, so i reffer > to JNC's endpoint docuemnte where several really nice definition of endpoint > can be found. > > The definition are (so you don't have to look for it) > > "To recap, however, an "endpoint" is, in order of increasing > formality: > > - one participant of an end-end communication > - the fundamental agent of end-end communication > - the entity which is performing a reliable communication on an > end-end basis > > - a fatesharing region > - a boundary drawn around a set of state and/or computations such > that it lives or dies as a unit" > > So, so far i like using endpoint because we have a definition for it and > IMHO it suit our needs. That is fine, as long as end system in RFC 1958 is no differnt from end point in Saltzer's paper. Can we reach the consensus? >>Forget NSRG. > > > Why? Because it is a new terminology useful for no new goals. > stack is also well defined in the nsrg report as: ". A stack is defined as > one participant or the process on one side of an end-to-end communication. > " People who engaged in NSRG activity has demonstrated that it is no well defined. However, if they repent that "stack" is identical to "end system" of RFC1958 and Saltzer's "end point", I'm fine, though we still have no reason to introduce terminlogy of "stack". > I haven't been able to find a definition for end-system, See RFC1958, especially, its reference. Masataka Ohta From owner-multi6@ops.ietf.org Tue Dec 9 10:38:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00631 for ; Tue, 9 Dec 2003 10:38:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATjvO-0004e3-2S for multi6-data@psg.com; Tue, 09 Dec 2003 15:37:22 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATjvB-0004cq-Mr for multi6@ops.ietf.org; Tue, 09 Dec 2003 15:37:10 +0000 Received: (qmail 65352 invoked from network); 9 Dec 2003 15:38:18 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 9 Dec 2003 15:38:18 -0000 Message-ID: <3FD5ECB6.9010305@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Dec 2003 00:39: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: mbagnulo@ing.uc3m.es, Kurt Erik Lindqvist , Dave Crocker , multi6@ops.ietf.org Subject: Re: This conversation is over [Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals]] References: <3FD5D5ED.55ACA737@zurich.ibm.com> In-Reply-To: <3FD5D5ED.55ACA737@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > It's my fault for mentioning the need to document our terminology, > but this thread serves no useful purpose for multi6 that I can see. > I suggest that those interested now continue it off-list. If you are saying Erik's threats draft serves no useful purpose for multi6, I can agree with you. However, if you are not, we still have to discuss any possible usefulness of Erik's and my threats drafts. We agreed in the last meeting that we will have multiple drafts, as not all of us are satisfied with Erik's. You may still argue against, as long as you won't wear the hat. Masataka Ohta From owner-multi6@ops.ietf.org Tue Dec 9 10:43:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00710 for ; Tue, 9 Dec 2003 10:43:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATjzp-0005g0-Ad for multi6-data@psg.com; Tue, 09 Dec 2003 15:41:57 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATjzd-0005fA-Do for multi6@ops.ietf.org; Tue, 09 Dec 2003 15:41:45 +0000 Received: (qmail 65370 invoked from network); 9 Dec 2003 15:42:54 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 9 Dec 2003 15:42:54 -0000 Message-ID: <3FD5EDC9.1090709@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Dec 2003 00:44:09 +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: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: <20031209152848.33F9C872D6@mercury.lcs.mit.edu> In-Reply-To: <20031209152848.33F9C872D6@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Noel; > This is rather different from the case of the term "identifier", where > clearly there have been people with very different assumptions as to what > that term meant. So I would therefore suggest (based on prior bitter > experience with the word "address") that any documents we create use some > *new* term, and *not* "identifier", for whatever name we come up with that > identifies the end-things (without giving their location). What's wrong if the exsiting terminology of "idenfifier" identifies exsisting terminology of "the end-things", that is, an end point or an end system? Masataka Ohta From owner-multi6@ops.ietf.org Tue Dec 9 10:48:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00900 for ; Tue, 9 Dec 2003 10:48:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATk4u-0006fS-Sn for multi6-data@psg.com; Tue, 09 Dec 2003 15:47:12 +0000 Received: from [194.112.11.163] (helo=mariehamn.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATk4g-0006eU-Hl for multi6@ops.ietf.org; Tue, 09 Dec 2003 15:46:58 +0000 Received: from localhost (localhost [127.0.0.1]) by mariehamn.kurtis.pp.se (Postfix) with ESMTP id 160A95F3; Tue, 9 Dec 2003 17:50:35 +0200 (EET) Date: Tue, 9 Dec 2003 17:50:34 +0200 (EET) From: Kurtis Lindqvist To: Masataka Ohta Cc: Brian E Carpenter , mbagnulo@ing.uc3m.es, multi6@ops.ietf.org Subject: Re: additional attack for multi6 threat draft? In-Reply-To: <3FD5E8CA.6040606@necom830.hpcl.titech.ac.jp> Message-ID: <20031209174826.X48591@mariehamn.kurtis.pp.se> References: <3FD59886.491A67E9@zurich.ibm.com> <3FD59EAD.3070706@necom830.hpcl.titech.ac.jp> <3FD5D561.B0078703@zurich.ibm.com> <3FD5E8CA.6040606@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk > > Yes, I am sure I am co-chair of this WG. > > I am not. I can confirm. Brian is my co-chair of this WG. > Or, are you sure that draft-nordmark-multi6-threats-00.txt is a WG > draft? It is not an official working-group draft, but it is a draft that is the result of discussions in here among other places. I don't think this discussion is leading us further so I think we can drop it here. - kurtis - From owner-multi6@ops.ietf.org Tue Dec 9 11:06:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01565 for ; Tue, 9 Dec 2003 11:06:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATkM4-000AKR-F6 for multi6-data@psg.com; Tue, 09 Dec 2003 16:04:56 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATkLs-000AGa-4o for multi6@ops.ietf.org; Tue, 09 Dec 2003 16:04:44 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D20F8872D6; Tue, 9 Dec 2003 10:37:30 -0500 (EST) To: multi6@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] Cc: jnc@mercury.lcs.mit.edu Message-Id: <20031209153730.D20F8872D6@mercury.lcs.mit.edu> Date: Tue, 9 Dec 2003 10:37:30 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Masataka Ohta >> could you provide a definition of what do you mean by end system? > As I searched reference of the RFC, "end point" seems to be an > alternative wording of "end system" that if JNC is saying "endpoint" > with the difinition of Saltzer's paper, that is fine. Which Saltzer paper? "End-End arguments", or RFC-1498 (which is the paper that first pointed out that we needed to separate location and identity)? In any event, there is a *significant* difference between my definition, and Saltzer's paper: he talks (basically) of hosts (i.e. physical boxes), whereas my "endpoint" definition is deliberately not tied to hardware. This has the very important *practical* difference that at one particular location in the network (i.e. whether one thinks that our "location-names" name interfaces, or are topology-dependent names for end-things) one could conceivably find *more than one* end-thing - e.g. if a host contains (for whatever reason) two endpoints. If so, the packet needs to contain some disambiguator to allow deliver to the proper end-thing. Many schemes for doing location/identity separation don't provide this. E.g. naive versions of 8+8, where the lower 64 bits is just the IEEE number, don't. Whether it's an important engineering goal is not for me to say - I'm just pointing it out. Also, although my definition would allow it (unlike Saltzer's), I'm not sure that in the real world, you'd ever see endpoints which cover more than one machine. Since endpoints are names for transport-level entities, in practical terms this would mean that if one host in a cluster died in the middle of a TCP connection, another could take up the connection, which would mean it would have to know which packets had been ACK'ed, etc. In the real world, nobody builds systems this way - you'd have to do a 2-phase commit or something between the machines of the server on every packet to the client! So perhaps this tells me that applications like the Web that want to be robust need *another*, higher, level of naming, for a service - but that's not our concern. Noel From owner-multi6@ops.ietf.org Tue Dec 9 11:06:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01604 for ; Tue, 9 Dec 2003 11:06:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATkN4-000AXd-BM for multi6-data@psg.com; Tue, 09 Dec 2003 16:05:58 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATkMs-000AWz-0i for multi6@ops.ietf.org; Tue, 09 Dec 2003 16:05:46 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id hB9G5cn0112466; Tue, 9 Dec 2003 16:05:38 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hB9G5bEl260844; Tue, 9 Dec 2003 17:05:38 +0100 Received: from zurich.ibm.com (sig-9-145-241-249.de.ibm.com [9.145.241.249]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA30362; Tue, 9 Dec 2003 17:05:35 +0100 Message-ID: <3FD5F29A.18AF2E10@zurich.ibm.com> Date: Tue, 09 Dec 2003 17:04: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: Iljitsch van Beijnum CC: Multi6 Mailing List Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: <637CEC9E-2994-11D8-9318-000A9598A184@kurtis.pp.se> <3FD59802.AAF3FA47@zurich.ibm.com> <3FD59FBF.8080807@necom830.hpcl.titech.ac.jp> <3FD5A564.969AE2FD@zurich.ibm.com> <87AD82EC-2A55-11D8-9581-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On 9-dec-03, at 11:35, Brian E Carpenter wrote: > > > In practical terms it matters very much. If the end point is > > distributed, > > multihoming it is a much more complex operation (assuming you want > > sessions > > to survive a multihoming event). Perhaps if you speak to some people > > actually implementing virtualized server pools this would be clearer > > to you. > > This depends where we put the demarcation point. I think a place that > puts multihoming functionality on one side, and host virtuality on the > other would be a very good choice. In other words: this is something > for the cluster software implementers to worry about. Architecturally, I agree. The devil is in the details, i.e. avoiding the need for the cluster software to contain even more outrageous hacks than today to make the virtualization work. Brian From owner-multi6@ops.ietf.org Tue Dec 9 16:51:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18926 for ; Tue, 9 Dec 2003 16:51:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATpkg-0004Zh-6h for multi6-data@psg.com; Tue, 09 Dec 2003 21:50:42 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATpkT-0004YG-QY for multi6@ops.ietf.org; Tue, 09 Dec 2003 21:50:30 +0000 Received: (qmail 66763 invoked from network); 9 Dec 2003 21:51:42 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 9 Dec 2003 21:51:42 -0000 Message-ID: <3FD64436.7080103@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Dec 2003 06:52:54 +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: Kurtis Lindqvist CC: Brian E Carpenter , mbagnulo@ing.uc3m.es, multi6@ops.ietf.org Subject: Re: additional attack for multi6 threat draft? References: <3FD59886.491A67E9@zurich.ibm.com> <3FD59EAD.3070706@necom830.hpcl.titech.ac.jp> <3FD5D561.B0078703@zurich.ibm.com> <3FD5E8CA.6040606@necom830.hpcl.titech.ac.jp> <20031209174826.X48591@mariehamn.kurtis.pp.se> In-Reply-To: <20031209174826.X48591@mariehamn.kurtis.pp.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurtis; >>>Yes, I am sure I am co-chair of this WG. >> >>I am not. > I can confirm. Brian is my co-chair of this WG. Then, who are you? >>Or, are you sure that draft-nordmark-multi6-threats-00.txt is a WG >>draft? > It is not an official working-group draft, but it is a draft that is the > result of discussions in here among other places. And, the result is that it was not chosen as the WG document. > I don't think this discussion is leading us further so I think we can drop > it here. If either of you were acting as a chair, you have better things to do other than confusing terminologies and interrupting an active thread Masataka Ohta From owner-multi6@ops.ietf.org Tue Dec 9 17:01:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19433 for ; Tue, 9 Dec 2003 17:01:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATpuA-00061I-Px for multi6-data@psg.com; Tue, 09 Dec 2003 22:00:30 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATpty-00060X-5R for multi6@ops.ietf.org; Tue, 09 Dec 2003 22:00:18 +0000 Received: (qmail 66817 invoked from network); 9 Dec 2003 22:01:31 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 9 Dec 2003 22:01:31 -0000 Message-ID: <3FD64682.7050100@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Dec 2003 07:02:42 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Noel Chiappa CC: multi6@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: <20031209153730.D20F8872D6@mercury.lcs.mit.edu> In-Reply-To: <20031209153730.D20F8872D6@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Noel; > > From: Masataka Ohta > > >> could you provide a definition of what do you mean by end system? > > > As I searched reference of the RFC, "end point" seems to be an > > alternative wording of "end system" that if JNC is saying "endpoint" > > with the difinition of Saltzer's paper, that is fine. > > Which Saltzer paper? "End-End arguments", or RFC-1498 (which is the paper > that first pointed out that we needed to separate location and identity)? > > In any event, there is a *significant* difference between my definition, and > Saltzer's paper: he talks (basically) of hosts (i.e. physical boxes), whereas > my "endpoint" definition is deliberately not tied to hardware. Then, you must find another wording, though there is no point insisting your point. > This has the very important *practical* difference that at one particular > location in the network (i.e. whether one thinks that our "location-names" > name interfaces, or are topology-dependent names for end-things) one could > conceivably find *more than one* end-thing - e.g. if a host contains (for > whatever reason) two endpoints. If end things are found at one particular location, which is the *PRACTICAL* assumption, they share connectivity fate that thier is nothing for M6 to worry about. > If so, the packet needs to contain some > disambiguator to allow deliver to the proper end-thing. When a host has complex internal structure, feel free to something, say, a port number, beyond a host address(es) for the disambiguation. > Many schemes for doing location/identity separation don't provide this. E.g. > naive versions of 8+8, where the lower 64 bits is just the IEEE number, > don't. Whether it's an important engineering goal is not for me to say - I'm > just pointing it out. Be practical. Masataka Ohta From owner-multi6@ops.ietf.org Tue Dec 9 17:02:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19472 for ; Tue, 9 Dec 2003 17:02:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATpue-000657-Mb for multi6-data@psg.com; Tue, 09 Dec 2003 22:01:00 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1ATpuR-00063n-0F for multi6@ops.ietf.org; Tue, 09 Dec 2003 22:00:47 +0000 Received: (qmail 66821 invoked from network); 9 Dec 2003 22:02:00 -0000 Received: from h219-110-032-001.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.1) by necom830.hpcl.titech.ac.jp with SMTP; 9 Dec 2003 22:02:00 -0000 Message-ID: <3FD646A0.70102@necom830.hpcl.titech.ac.jp> Date: Wed, 10 Dec 2003 07:03: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: Iljitsch van Beijnum , Multi6 Mailing List Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: <637CEC9E-2994-11D8-9318-000A9598A184@kurtis.pp.se> <3FD59802.AAF3FA47@zurich.ibm.com> <3FD59FBF.8080807@necom830.hpcl.titech.ac.jp> <3FD5A564.969AE2FD@zurich.ibm.com> <87AD82EC-2A55-11D8-9581-000A95CD987A@muada.com> <3FD5F29A.18AF2E10@zurich.ibm.com> In-Reply-To: <3FD5F29A.18AF2E10@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Iljitsch van Beijnum wrote: > Brian; >>>In practical terms it matters very much. If the end point is >>>distributed, >>>multihoming it is a much more complex operation (assuming you want >>>sessions >>>to survive a multihoming event). Perhaps if you speak to some people >>>actually implementing virtualized server pools this would be clearer >>>to you. >> >>This depends where we put the demarcation point. I think a place that >>puts multihoming functionality on one side, and host virtuality on the >>other would be a very good choice. In other words: this is something >>for the cluster software implementers to worry about. > Architecturally, I agree. The devil is in the details, i.e. avoiding the > need for the cluster software to contain even more outrageous hacks > than today to make the virtualization work. Discontinue this thread. It is useless for any M6 purpose. Masataka Ohta From owner-multi6@ops.ietf.org Wed Dec 10 02:22:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24519 for ; Wed, 10 Dec 2003 02:22:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATydL-000I8q-Vo for multi6-data@psg.com; Wed, 10 Dec 2003 07:19:43 +0000 Received: from [194.112.11.163] (helo=mariehamn.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATyct-000I8E-5y for multi6@ops.ietf.org; Wed, 10 Dec 2003 07:19:15 +0000 Received: from localhost (localhost [127.0.0.1]) by mariehamn.kurtis.pp.se (Postfix) with ESMTP id 9791D614; Wed, 10 Dec 2003 09:22:56 +0200 (EET) Date: Wed, 10 Dec 2003 09:22:56 +0200 (EET) From: Kurtis Lindqvist To: Masataka Ohta Cc: Brian E Carpenter , mbagnulo@ing.uc3m.es, multi6@ops.ietf.org Subject: Re: additional attack for multi6 threat draft? In-Reply-To: <3FD64436.7080103@necom830.hpcl.titech.ac.jp> Message-ID: <20031210092050.Q67412@mariehamn.kurtis.pp.se> References: <3FD59886.491A67E9@zurich.ibm.com> <3FD59EAD.3070706@necom830.hpcl.titech.ac.jp> <3FD5D561.B0078703@zurich.ibm.com> <3FD5E8CA.6040606@necom830.hpcl.titech.ac.jp> <20031209174826.X48591@mariehamn.kurtis.pp.se> <3FD64436.7080103@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Ohta-san, > > It is not an official working-group draft, but it is a draft that is the > > result of discussions in here among other places. > > And, the result is that it was not chosen as the WG document. This question has never been asked. It probably will be, but it hasn't. And as a matter of fact, you are the only one I see disagreeing. You do not make up this WG. > > I don't think this discussion is leading us further so I think we can drop > > it here. > > If either of you were acting as a chair, you have better things to > do other than confusing terminologies and interrupting an active > thread An active thread is not the same as a constructive or contributing thread. If you want to continue the thread, post comments and details on the proposals. - kurtis - From owner-multi6@ops.ietf.org Wed Dec 10 03:01:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03521 for ; Wed, 10 Dec 2003 03:01:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ATzH8-000Lxm-9W for multi6-data@psg.com; Wed, 10 Dec 2003 08:00:50 +0000 Received: from [194.112.11.163] (helo=mariehamn.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATzGv-000LwA-Uf for multi6@ops.ietf.org; Wed, 10 Dec 2003 08:00:38 +0000 Received: from localhost (localhost [127.0.0.1]) by mariehamn.kurtis.pp.se (Postfix) with ESMTP id 7CFAE614; Wed, 10 Dec 2003 10:04:20 +0200 (EET) Date: Wed, 10 Dec 2003 10:04:20 +0200 (EET) From: Kurtis Lindqvist To: Masataka Ohta Cc: Brian E Carpenter , mbagnulo@ing.uc3m.es, multi6@ops.ietf.org Subject: Re: additional attack for multi6 threat draft? In-Reply-To: <20031210092050.Q67412@mariehamn.kurtis.pp.se> Message-ID: <20031210100349.L67412@mariehamn.kurtis.pp.se> References: <3FD59886.491A67E9@zurich.ibm.com> <3FD59EAD.3070706@necom830.hpcl.titech.ac.jp> <3FD5D561.B0078703@zurich.ibm.com> <3FD5E8CA.6040606@necom830.hpcl.titech.ac.jp> <20031209174826.X48591@mariehamn.kurtis.pp.se> <3FD64436.7080103@necom830.hpcl.titech.ac.jp> <20031210092050.Q67412@mariehamn.kurtis.pp.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 10 Dec 2003, Kurtis Lindqvist wrote: [snip] > An active thread is not the same as a constructive or contributing thread. > If you want to continue the thread, post comments and details on the > proposals. > > - kurtis - WG-chair hat on - kurtis - From owner-multi6@ops.ietf.org Wed Dec 10 06:06:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07232 for ; Wed, 10 Dec 2003 06:06:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AU284-000DJt-Eo for multi6-data@psg.com; Wed, 10 Dec 2003 11:03:40 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AU27r-000DJT-O2 for multi6@ops.ietf.org; Wed, 10 Dec 2003 11:03:27 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBAB3PPg090610 for ; Wed, 10 Dec 2003 11:03:25 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hBAB3PAd241402 for ; Wed, 10 Dec 2003 12:03:25 +0100 Received: from zurich.ibm.com ([9.145.151.102]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA20780 for ; Wed, 10 Dec 2003 12:03:23 +0100 Message-ID: <3FD6FD46.11303519@zurich.ibm.com> Date: Wed, 10 Dec 2003 12:02: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@ops.ietf.org Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals] References: <20031209153730.D20F8872D6@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Well, this is actually an interesting discussion in the e2e context, but the co-chairs are definitely of the opinion that it's gone beyond the point of helping multi6 achieve its goals. So, folks, please continue on some other list... Brian Noel Chiappa wrote: > > > From: Masataka Ohta > > >> could you provide a definition of what do you mean by end system? > > > As I searched reference of the RFC, "end point" seems to be an > > alternative wording of "end system" that if JNC is saying "endpoint" > > with the difinition of Saltzer's paper, that is fine. > > Which Saltzer paper? "End-End arguments", or RFC-1498 (which is the paper > that first pointed out that we needed to separate location and identity)? > > In any event, there is a *significant* difference between my definition, and > Saltzer's paper: he talks (basically) of hosts (i.e. physical boxes), whereas > my "endpoint" definition is deliberately not tied to hardware. > > This has the very important *practical* difference that at one particular > location in the network (i.e. whether one thinks that our "location-names" > name interfaces, or are topology-dependent names for end-things) one could > conceivably find *more than one* end-thing - e.g. if a host contains (for > whatever reason) two endpoints. If so, the packet needs to contain some > disambiguator to allow deliver to the proper end-thing. > > Many schemes for doing location/identity separation don't provide this. E.g. > naive versions of 8+8, where the lower 64 bits is just the IEEE number, > don't. Whether it's an important engineering goal is not for me to say - I'm > just pointing it out. > > Also, although my definition would allow it (unlike Saltzer's), I'm not sure > that in the real world, you'd ever see endpoints which cover more than one > machine. > > Since endpoints are names for transport-level entities, in practical terms > this would mean that if one host in a cluster died in the middle of a TCP > connection, another could take up the connection, which would mean it would > have to know which packets had been ACK'ed, etc. In the real world, nobody > builds systems this way - you'd have to do a 2-phase commit or something > between the machines of the server on every packet to the client! > > So perhaps this tells me that applications like the Web that want to be > robust need *another*, higher, level of naming, for a service - but that's > not our concern. > > Noel -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-multi6@ops.ietf.org Thu Dec 11 10:15:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05245 for ; Thu, 11 Dec 2003 10:15:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AUSSp-000Bxh-AC for multi6-data@psg.com; Thu, 11 Dec 2003 15:10:51 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AUSSb-000BwQ-FS for multi6@ops.ietf.org; Thu, 11 Dec 2003 15:10:37 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Dec 2003 07:12:57 +0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBBFAZBN005035 for ; Thu, 11 Dec 2003 07:10:35 -0800 (PST) Received: from cisco.com (dhcp-ams-cam-wvlan23-144-254-207-39.cisco.com [144.254.207.39]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA11569 for ; Thu, 11 Dec 2003 07:10:34 -0800 (PST) Message-ID: <3FD888E9.70500@cisco.com> Date: Thu, 11 Dec 2003 07:10:33 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: draft-lear-mulit6-things-to-think-about-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ... should be in the internet-draft by tomorrow. Having sent it off, I realize I missed two biggies, but this highlights that the draft is -00. All feedback welcome. Organization still needs a little work, but I rather folk first tell me what questions are missing. If you don't find this useful, please let me know (preferrably without using a club). The two big questions I missed were: 1. What is the impact [of a particular solution] on debugging problems? Will netstat views change? What additional tools would be necessary/useful? 2. Is there any impact of your proposed solution on network management tools? Any new dependencies? They're in -01. Eliot From owner-multi6@ops.ietf.org Tue Dec 16 03:32:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04389 for ; Tue, 16 Dec 2003 03:32:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AWAYi-000Hol-Ev for multi6-data@psg.com; Tue, 16 Dec 2003 08:28:00 +0000 Received: from [195.212.29.156] (helo=mtagate7.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AWAYF-000Hms-8V for multi6@ops.ietf.org; Tue, 16 Dec 2003 08:27:31 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate7.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBG8RTwj127994 for ; Tue, 16 Dec 2003 08:27:29 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 hBG8RTkj259582 for ; Tue, 16 Dec 2003 09:27:29 +0100 Received: from zurich.ibm.com (sig-9-145-240-47.de.ibm.com [9.145.240.47]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA33232 for ; Tue, 16 Dec 2003 09:27:27 +0100 Message-ID: <3FDEC1B7.FF2655CA@zurich.ibm.com> Date: Tue, 16 Dec 2003 09:26:31 +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-lear-multi6-things-to-think-about-00.txt] Content-Type: multipart/mixed; boundary="------------F180A9204871DF0BAE26AF0F" X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------F180A9204871DF0BAE26AF0F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit fyi -------- Original Message -------- Subject: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt Date: Mon, 15 Dec 2003 15:29:00 -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 : Things MULTI6 Developers should think about Author(s) : E. Lear Filename : draft-lear-multi6-things-to-think-about-00.txt Pages : 12 Date : 2003-12-15 This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution either. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-think-about-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-lear-multi6-things-to-think-about-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-lear-multi6-things-to-think-about-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. --------------F180A9204871DF0BAE26AF0F Content-Type: Message/External-body; name="draft-lear-multi6-things-to-think-about-00.txt" Content-Disposition: inline; filename="draft-lear-multi6-things-to-think-about-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-12-15150315.I-D@ietf.org> --------------F180A9204871DF0BAE26AF0F-- From owner-multi6@ops.ietf.org Tue Dec 16 04:42:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06291 for ; Tue, 16 Dec 2003 04:42:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AWBfk-000NKL-92 for multi6-data@psg.com; Tue, 16 Dec 2003 09:39:20 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AWBfV-000NJi-90 for multi6@ops.ietf.org; Tue, 16 Dec 2003 09:39:05 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3D2A0657 for ; Tue, 16 Dec 2003 10:39:04 +0100 (CET) Received: from lolo (lolo.lab.it.uc3m.es [163.117.144.27]) by smtp01.uc3m.es (Postfix) with SMTP id 2A353605 for ; Tue, 16 Dec 2003 10:39:04 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Multi6" Subject: RE: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] Date: Tue, 16 Dec 2003 10:32:16 +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: <3FDEC1B7.FF2655CA@zurich.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, i think this draft will be useful I have some additional questions for your consideration: - Is the multi-homing solution IPv6 only or can it also be used with IPv4? I know this is multi6, but it is probably interesting to know if the solution can be applied to IPv4 - Does your solution applies to all type of sites?, for instance is your solution suitable for very small sites? (does it requires an expert administrator o very powerful equipment) is your solution siutable for very large sites? - About incremental deployment, i think that there are different ideas about what incremental deployment means. So perhaps we could ask more specific question (in addition) like: - Does your solution imposes changes outside the multi-homed site? - what do you need to change in the mh site? in particular if you plug in a non upgraded IPv6 node, does it work properly? can it communicate outside the mhsite? does it obtain multi-homing benefits? - Does your solution requires some global infrastructure to start working? like a new global DNS like system, or it allows two upgraded nodes to communicate with each other without any additional infrastructure - If your solution preserves established communications, does it introduces overhead? additional data? additional processing in the nodes? How does your solution distributes the overhead? does it imposes additional overhead on a per communication basis or a per node basis? does it imposes extra overhead to all communications? does it imposes additional overhead for those communications that don't suffer an outage along its path? does it only imposes overhead after the outage? - Impact od DNS, does you solution will impose an additional significant stress to the DNS system? like how much more DNS queries are expected Regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Brian E Carpenter > Enviado el: martes, 16 de diciembre de 2003 9:27 > Para: Multi6 > Asunto: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] > > > fyi > > -------- Original Message -------- > Subject: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt > Date: Mon, 15 Dec 2003 15:29:00 -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 : Things MULTI6 Developers should think about > Author(s) : E. Lear > Filename : draft-lear-multi6-things-to-think-about-00.txt > Pages : 12 > Date : 2003-12-15 > > This document specifies a set of questions that authors should be > prepared to answer as part of a solution to multihoming with IPv6. > The questions do not assume that multihoming is the only problem of > interest, nor do they demand a more general solution either. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-th ink-about-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-lear-multi6-things-to-think-about-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-lear-multi6-things-to-think-about-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 Tue Dec 16 11:05:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21481 for ; Tue, 16 Dec 2003 11:05:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AWHdQ-00046K-MN for multi6-data@psg.com; Tue, 16 Dec 2003 16:01:20 +0000 Received: from [192.71.80.97] (helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AWHdD-00045X-EH for multi6@ops.ietf.org; Tue, 16 Dec 2003 16:01:07 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.9/8.12.6) with ESMTP id hBGG14sD025821; Tue, 16 Dec 2003 17:01:04 +0100 (CET) Date: Tue, 16 Dec 2003 17:00:57 +0100 Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v553) Cc: "Multi6" To: From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <091B4ACF-2FE1-11D8-A005-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.553) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > - Is the multi-homing solution IPv6 only or can it also be used with > IPv4? > I know this is multi6, but it is probably interesting to know if the > solution can be applied to IPv4 To be honest, I think this is not important right now. Let's solve the task at hand first. If we after that figures out that it works for IPv4 as well, all the better. > - Does your solution applies to all type of sites?, for instance is > your > solution suitable for very small sites? (does it requires an expert > administrator o very powerful equipment) is your solution siutable for > very > large sites? I think this might be a subjective judgment. Not sure it makes sense to take into account right now. But no strong feeling one way or the other. > - About incremental deployment, i think that there are different ideas > about > what incremental deployment means. Maybe what we would need is to have each proposal include a description of how the proposal is implemented in a site/network? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP98sPaarNKXTPFCVEQJm5QCfdu+LMFjcBtHEJT5jhcD/RUSi84YAnios n3GTWzWlfMKL0qD5PdEtSDwC =DG71 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Dec 16 12:33:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24798 for ; Tue, 16 Dec 2003 12:33:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AWJ36-000Csf-5Z for multi6-data@psg.com; Tue, 16 Dec 2003 17:31:56 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AWJ2u-000Crn-3J for multi6@ops.ietf.org; Tue, 16 Dec 2003 17:31:44 +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 hBGJb1Ot016809; Tue, 16 Dec 2003 11:37:01 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id hBGHVVYB019797; Tue, 16 Dec 2003 09:31:31 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] Date: Tue, 16 Dec 2003 09:31:31 -0800 Message-ID: Thread-Topic: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] Thread-Index: AcPD8EyC2s0Zz2byQGmMGCh9YmtXsAACXiKQ From: "Tony Li" To: "Kurt Erik Lindqvist" , Cc: "Multi6" X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable | > - Is the multi-homing solution IPv6 only or can it also be=20 | used with=20 | > IPv4? | > I know this is multi6, but it is probably interesting to=20 | know if the | > solution can be applied to IPv4 | =20 | To be honest, I think this is not important right now. Let's=20 | solve the=20 | task at hand first. If we after that figures out that it=20 | works for IPv4=20 | as well, all the better. I'd submit that if it cannot be easily ported back to IPv4, that it bears closer examination. v4 and v6 are architecturally very similar. Any solution that does not apply to both is either a kludge or is exploiting an odd property of one of the two. In either case, it would bear close examination. You know, the kind that you give things when the fire alarm in the building goes off... ? ;-) | > - Does your solution applies to all type of sites?, for=20 | instance is=20 | > your | > solution suitable for very small sites? (does it requires an expert | > administrator o very powerful equipment) is your solution=20 | siutable for=20 | > very | > large sites? | =20 | I think this might be a subjective judgment. Not sure it=20 | makes sense to=20 | take into account right now. But no strong feeling one way=20 | or the other. I think that the question is valid, regardless. However, I don't think that this is a _requirement_, which is what I think you were saying. | > - About incremental deployment, i think that there are=20 | different ideas=20 | > about | > what incremental deployment means. | =20 | Maybe what we would need is to have each proposal include a=20 | description=20 | of how the proposal is implemented in a site/network? Deployability is always a good thing for running code... ;-) Yes, I think any proposal needs to describe a plausible deployment scenario. Tony From owner-multi6@ops.ietf.org Tue Dec 16 20:20:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18428 for ; Tue, 16 Dec 2003 20:20:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWQK4-0008rj-Ry for multi6-data@psg.com; Wed, 17 Dec 2003 01:17:56 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWQJq-0008jg-TV for multi6@ops.ietf.org; Wed, 17 Dec 2003 01:17:42 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Dec 2003 17:20:47 +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 hBH1HdAt017084; Tue, 16 Dec 2003 17:17:40 -0800 (PST) Received: from cisco.com (sjc-vpn1-546.cisco.com [10.21.98.34]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA22799; Tue, 16 Dec 2003 17:17:39 -0800 (PST) Message-ID: <3FDFAEB3.1010807@cisco.com> Date: Tue, 16 Dec 2003 17:17:39 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es CC: Multi6 Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-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.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 Marcelo, > - Is the multi-homing solution IPv6 only or can it also be used with IPv4? > I know this is multi6, but it is probably interesting to know if the > solution can be applied to IPv4 This is worth while answering, for the reasons Tony mentions. However, just because a solution works for v6 but not for v4 (say making use of the flow label that doesn't exist in v4) does not disqualify it as a right proper solution to the problem at hand. As we've discussed in person and on the list, v4 is a bonus if we can get it. > - Does your solution applies to all type of sites?, for instance is your > solution suitable for very small sites? (does it requires an expert > administrator o very powerful equipment) is your solution siutable for very > large sites? I think there is a related question I also failed to ask: what sort of support from upstreams and the registries does your solution require (if any)? > > - About incremental deployment, i think that there are different ideas about > what incremental deployment means. So perhaps we could ask more specific > question (in addition) like: > - Does your solution imposes changes outside the multi-homed site? Right- that's in there (at least in part), but see above as well. > - what do you need to change in the mh site? in particular if > you plug in a non upgraded IPv6 node, does it work properly? can it > communicate outside the mhsite? does it obtain multi-homing benefits? This is a good question, and also was not clear in the draft. If the mechanism can make use of stateless autoconfiguration or DHCP in some way to enable itself (at least at the conceptual level) that would be nice. Here's a question: do nodes all know who they are? How do they gain their knowledge? Is there a change to dhcp or stateless autoconfiguration? If so, describe. > - Does your solution requires some global infrastructure to start > working? like a new global DNS like system, or it allows two upgraded nodes > to communicate with each other without any additional infrastructure that's also in there. > > - If your solution preserves established communications, does it introduces > overhead? additional data? additional processing in the nodes? How does your > solution distributes the overhead? does it imposes additional overhead on a > per communication basis or a per node basis? does it imposes extra overhead > to all communications? does it imposes additional overhead for those > communications that don't suffer an outage along its path? does it only > imposes overhead after the outage? Your question was a bit more general than what I wrote. I talked about packet expansion, but I did not talk about exchanges that might add latency, and that will need to be added in the next version (I'll put it out the first week in January). > > - Impact od DNS, does you solution will impose an additional significant > stress to the DNS system? like how much more DNS queries are expected The number of queries were not addressed; this is a good question, especially if the mechanism will screw up normal DNS caching semantics in some way, or othrewise will be screwed up by those same semantics. Happy Holidays, Eliot From owner-multi6@ops.ietf.org Wed Dec 17 10:29:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13799 for ; Wed, 17 Dec 2003 10:29:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWdWr-000HbQ-9b for multi6-data@psg.com; Wed, 17 Dec 2003 15:24:01 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWdWd-000HbA-VK for multi6@ops.ietf.org; Wed, 17 Dec 2003 15:23:48 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWdWd-000PQL-L8 for multi6@ops.ietf.org; Wed, 17 Dec 2003 07:23:47 -0800 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Wed, 17 Dec 2003 08:11:20 +0200 (EET) From: Pekka Savola To: Tony Li cc: Kurt Erik Lindqvist , , Multi6 Subject: RE: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] In-Reply-To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Message-Id: On Tue, 16 Dec 2003, Tony Li wrote: > I'd submit that if it cannot be easily ported back to IPv4, that it > bears closer examination. v4 and v6 are architecturally very > similar. Any solution that does not apply to both is either a > kludge or is exploiting an odd property of one of the two. In > either case, it would bear close examination. You know, the kind > that you give things when the fire alarm in the building goes off... > ? ;-) I have to heartily disagree here. IPv6 address *does* have more bits. Different problem spaces have leveraged that property before as well, leading to solutions which are not easily backportable to IPv4. Maybe one could reword this differently: the solution beas some thinking about if it doesn't rely on the 128bit address length of IPv6, and is not easily IPv4-capable. -- 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 Thu Dec 18 03:58:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11781 for ; Thu, 18 Dec 2003 03:58:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWtwX-0002bo-JQ for multi6-data@psg.com; Thu, 18 Dec 2003 08:55:37 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWtwI-0002aJ-8l for multi6@ops.ietf.org; Thu, 18 Dec 2003 08:55:22 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBI8tHCB136484 for ; Thu, 18 Dec 2003 08:55:17 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 hBI8tGk5232126 for ; Thu, 18 Dec 2003 09:55:16 +0100 Received: from zurich.ibm.com (sig-9-145-225-19.de.ibm.com [9.145.225.19]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA39838 for ; Thu, 18 Dec 2003 09:55:14 +0100 Message-ID: <3FE16B39.EA6D5EA5@zurich.ibm.com> Date: Thu, 18 Dec 2003 09:54:17 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > On Tue, 16 Dec 2003, Tony Li wrote: > > I'd submit that if it cannot be easily ported back to IPv4, that it > > bears closer examination. v4 and v6 are architecturally very > > similar. Any solution that does not apply to both is either a > > kludge or is exploiting an odd property of one of the two. In > > either case, it would bear close examination. You know, the kind > > that you give things when the fire alarm in the building goes off... > > ? ;-) > > I have to heartily disagree here. IPv6 address *does* have more bits. > Different problem spaces have leveraged that property before as well, > leading to solutions which are not easily backportable to IPv4. > > Maybe one could reword this differently: the solution beas some > thinking about if it doesn't rely on the 128bit address length of > IPv6, and is not easily IPv4-capable. Yes. But this is the IPv6 multihoming WG, so while applicability to IPv4 is an interesting question to ask, it cannot be a decision criterion. I would counter-argue against Tony in another way. If we had variable length addresses (as some people strongly suggested for IPng) a whole new class of multihoming solutions might be available. But we don't, so they aren't. Thus, you cannot argue that solutions *must* be independent of address length considerations. (Please don't kick off a thread on variable length addresses... at least not here.) Brian From owner-multi6@ops.ietf.org Thu Dec 18 04:26:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12374 for ; Thu, 18 Dec 2003 04:26:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWuPd-0005GX-La for multi6-data@psg.com; Thu, 18 Dec 2003 09:25:41 +0000 Received: from [194.112.11.163] (helo=mariehamn.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWuPQ-0005FO-Im for multi6@ops.ietf.org; Thu, 18 Dec 2003 09:25:28 +0000 Received: from localhost (localhost [127.0.0.1]) by mariehamn.kurtis.pp.se (Postfix) with ESMTP id 3BD39614; Thu, 18 Dec 2003 11:30:13 +0200 (EET) Date: Thu, 18 Dec 2003 11:30:12 +0200 (EET) From: Kurtis Lindqvist To: Tony Li Cc: mbagnulo@ing.uc3m.es, Multi6 Subject: RE: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] In-Reply-To: Message-ID: <20031218112915.K86072@mariehamn.kurtis.pp.se> 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 > | > - Is the multi-homing solution IPv6 only or can it also be > | used with > | > IPv4? > | > I know this is multi6, but it is probably interesting to > | know if the > | > solution can be applied to IPv4 > | > | To be honest, I think this is not important right now. Let's > | solve the > | task at hand first. If we after that figures out that it > | works for IPv4 > | as well, all the better. > > > I'd submit that if it cannot be easily ported back to IPv4, that it > bears > closer examination. v4 and v6 are architecturally very similar. Any > solution that does not apply to both is either a kludge or is exploiting > an odd property of one of the two. In either case, it would bear close > examination. You know, the kind that you give things when the fire > alarm > in the building goes off... ? ;-) Yes, but what I am saying (and so is Brian in the latest mail) is that is not a target for this WG. > | > - About incremental deployment, i think that there are > | different ideas > | > about > | > what incremental deployment means. > | > | Maybe what we would need is to have each proposal include a > | description > | of how the proposal is implemented in a site/network? > > > Deployability is always a good thing for running code... ;-) > Yes, I think any proposal needs to describe a plausible deployment > scenario. Yes. - kurtis - From owner-multi6@ops.ietf.org Thu Dec 18 07:54:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18423 for ; Thu, 18 Dec 2003 07:54:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWxe7-0005DL-1w for multi6-data@psg.com; Thu, 18 Dec 2003 12:52:51 +0000 Received: from [204.127.202.55] (helo=sccrmhc11.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWxdv-0005Bh-5V for multi6@ops.ietf.org; Thu, 18 Dec 2003 12:52:39 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc11) with SMTP id <2003121812523801100klm5re> (Authid: sdawkins@comcast.net); Thu, 18 Dec 2003 12:52:38 +0000 Message-ID: <05cc01c3c565$d3a54ba0$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Multi6" References: <3FE16B39.EA6D5EA5@zurich.ibm.com> Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] Date: Thu, 18 Dec 2003 06:52:42 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.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 I may be misunderstanding something here, so let me ask the question before I expound. ----- Original Message ----- From: "Brian E Carpenter" To: "Multi6" Sent: Thursday, December 18, 2003 2:54 AM Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] > Pekka Savola wrote: > > > > Maybe one could reword this differently: the solution beas some > > thinking about if it doesn't rely on the 128bit address length of > > IPv6, and is not easily IPv4-capable. > > Yes. But this is the IPv6 multihoming WG, so while applicability to > IPv4 is an interesting question to ask, it cannot be a decision > criterion. I'm not sure what the difference between "bears some thinking about" and "being a decision criterion" is in Brian's mind. What I'm hoping Brian is saying is, "it's OK to notice whether a proposal works for IPv4, on this mailing list, but 'doesn't work for IPv4' can't be used to disqualify a proposal". The reason I'm asking is, I've been very aware that multi6 was willing to host discussions at the very edge of the WG's charter, because multi6 was the "least wrong" place to have these discussions. Sean Doran (former WG chair) said basically, "why the heck not?" on August 9, in the "loc/id split" thread. If Brian is saying that discussions about IPv4 suitability don't belong here, we need to find a place where they do belong. I THOUGHT that Leslie asked Geoff to set up a mailing list after the IAB workshop in Vienna, but the minutes at http://www.ietf.org/proceedings/03jul/127.htm don't show this action item. So, as Sean said, this is the least wrong place that exists today - how wrong is it? Spencer From owner-multi6@ops.ietf.org Thu Dec 18 09:23:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23039 for ; Thu, 18 Dec 2003 09:23:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AWz1w-000H3k-LQ for multi6-data@psg.com; Thu, 18 Dec 2003 14:21:32 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWz1j-000Gze-VA for multi6@ops.ietf.org; Thu, 18 Dec 2003 14:21:20 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hBIELcDP093878; Thu, 18 Dec 2003 15:21:38 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3FE16B39.EA6D5EA5@zurich.ibm.com> References: <3FE16B39.EA6D5EA5@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7284DA2E-3165-11D8-96B9-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] Date: Thu, 18 Dec 2003 15:21:19 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.606) 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 18-dec-03, at 9:54, Brian E Carpenter wrote: > I would counter-argue against Tony in another way. If we had variable > length addresses (as some people strongly suggested for IPng) a whole > new class of multihoming solutions might be available. But we don't, > so they aren't. Thus, you cannot argue that solutions *must* be > independent > of address length considerations. > (Please don't kick off a thread on variable length addresses... at > least not here.) Why not? I think that if we can do what we need to do by using variable length addressing, then the annoyance of having to cram those inside an IPv6 packet in a way that the packet remains routable is probably worth it. There is lots more in the draft that I don't feel particularly comfortable with. For instance, the mobility questions. From owner-multi6@ops.ietf.org Thu Dec 18 13:55:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08247 for ; Thu, 18 Dec 2003 13:55:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AX3Gx-0000Vo-DQ for multi6-data@psg.com; Thu, 18 Dec 2003 18:53:19 +0000 Received: from [65.174.124.37] (helo=dmz2.procket.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX3GU-0000TK-GJ for multi6@ops.ietf.org; Thu, 18 Dec 2003 18:52:50 +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 hBIKwFOt050964; Thu, 18 Dec 2003 12:58:15 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id hBIIqhYB008786; Thu, 18 Dec 2003 10:52:43 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] Date: Thu, 18 Dec 2003 10:52:43 -0800 Message-ID: Thread-Topic: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] Thread-Index: AcPFRrTdRM/L+2emT6GwxXeYzvbwbwAUNeKw From: "Tony Li" To: "Brian E Carpenter" , "Multi6" 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 Brian, I thought that the point of this document was things to think about, not a set of decision criteria. If it is a set of criteria, then aren't we duplicating the requirements draft? No, I don't want to reopen that, but what I *AM* suggesting is that Eliot's list is literally a list of discussion questions. As such, I think that this is a fine question to ask. If you're elevating this draft as anything other than a set of=20 discussion questions, then we need to have a different discussion. Which is it? Tony | -----Original Message----- | From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 | Sent: Thursday, December 18, 2003 12:54 AM | To: Multi6 | Subject: Re: [Fwd: I-D=20 | ACTION:draft-lear-multi6-things-to-think-about-00.txt] | =20 | =20 | Pekka Savola wrote: | >=20 | > On Tue, 16 Dec 2003, Tony Li wrote: | > > I'd submit that if it cannot be easily ported back to=20 | IPv4, that it | > > bears closer examination. v4 and v6 are architecturally very | > > similar. Any solution that does not apply to both is either a | > > kludge or is exploiting an odd property of one of the two. In | > > either case, it would bear close examination. You know, the kind | > > that you give things when the fire alarm in the building=20 | goes off... | > > ? ;-) | >=20 | > I have to heartily disagree here. IPv6 address *does*=20 | have more bits. | > Different problem spaces have leveraged that property=20 | before as well, | > leading to solutions which are not easily backportable to IPv4. | >=20 | > Maybe one could reword this differently: the solution beas some | > thinking about if it doesn't rely on the 128bit address length of | > IPv6, and is not easily IPv4-capable. | =20 | Yes. But this is the IPv6 multihoming WG, so while applicability to | IPv4 is an interesting question to ask, it cannot be a decision | criterion. | =20 | I would counter-argue against Tony in another way. If we had variable | length addresses (as some people strongly suggested for IPng) a whole | new class of multihoming solutions might be available. But we don't, | so they aren't. Thus, you cannot argue that solutions *must*=20 | be independent=20 | of address length considerations. | =20 | (Please don't kick off a thread on variable length addresses... at | least not here.) | =20 | Brian | =20 | =20 From owner-multi6@ops.ietf.org Thu Dec 18 15:14:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14021 for ; Thu, 18 Dec 2003 15:14:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AX4Vs-000Be9-Q6 for multi6-data@psg.com; Thu, 18 Dec 2003 20:12:48 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX4Vf-000Bd2-DM for multi6@ops.ietf.org; Thu, 18 Dec 2003 20:12:35 +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 hBIKCWBN027766; Thu, 18 Dec 2003 12:12:32 -0800 (PST) Received: from cisco.com (sjc-vpn1-148.cisco.com [10.21.96.148]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA09811; Thu, 18 Dec 2003 12:12:28 -0800 (PST) Message-ID: <3FE20A2B.6020607@cisco.com> Date: Thu, 18 Dec 2003 12:12:27 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: Brian E Carpenter , Multi6 Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-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.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Let's leave the legaleze out of this, but (hopefully) the document contains some questions that can be used to evaluate such minor issues as deployability, security, performance, and generality. The methods used might cause some conflict between these objectives. That's okay. We can decide which ones are important when we understand which tradeoffs are being made. Eliot ps: I'm leaving the "for instances..." out for brevity's sake. Tony Li wrote: > > Brian, > > I thought that the point of this document was things to think about, > not a set of decision criteria. If it is a set of criteria, then aren't > we duplicating the requirements draft? No, I don't want to reopen that, > but what I *AM* suggesting is that Eliot's list is literally a list > of discussion questions. As such, I think that this is a fine question > to ask. > > If you're elevating this draft as anything other than a set of > discussion questions, then we need to have a different discussion. > > Which is it? > > Tony > > > | -----Original Message----- > | From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > | Sent: Thursday, December 18, 2003 12:54 AM > | To: Multi6 > | Subject: Re: [Fwd: I-D > | ACTION:draft-lear-multi6-things-to-think-about-00.txt] > | > | > | Pekka Savola wrote: > | > > | > On Tue, 16 Dec 2003, Tony Li wrote: > | > > I'd submit that if it cannot be easily ported back to > | IPv4, that it > | > > bears closer examination. v4 and v6 are architecturally very > | > > similar. Any solution that does not apply to both is either a > | > > kludge or is exploiting an odd property of one of the two. In > | > > either case, it would bear close examination. You know, the kind > | > > that you give things when the fire alarm in the building > | goes off... > | > > ? ;-) > | > > | > I have to heartily disagree here. IPv6 address *does* > | have more bits. > | > Different problem spaces have leveraged that property > | before as well, > | > leading to solutions which are not easily backportable to IPv4. > | > > | > Maybe one could reword this differently: the solution beas some > | > thinking about if it doesn't rely on the 128bit address length of > | > IPv6, and is not easily IPv4-capable. > | > | Yes. But this is the IPv6 multihoming WG, so while applicability to > | IPv4 is an interesting question to ask, it cannot be a decision > | criterion. > | > | I would counter-argue against Tony in another way. If we had variable > | length addresses (as some people strongly suggested for IPng) a whole > | new class of multihoming solutions might be available. But we don't, > | so they aren't. Thus, you cannot argue that solutions *must* > | be independent > | of address length considerations. > | > | (Please don't kick off a thread on variable length addresses... at > | least not here.) > | > | Brian > | > | > > > From owner-multi6@ops.ietf.org Thu Dec 18 16:37:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22249 for ; Thu, 18 Dec 2003 16:37:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AX5oZ-000P6K-3G for multi6-data@psg.com; Thu, 18 Dec 2003 21:36:11 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX5oM-000P5H-Ro for multi6@ops.ietf.org; Thu, 18 Dec 2003 21:35:59 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.8p1/8.12.8) with ESMTP id hBILZYDP098770; Thu, 18 Dec 2003 22:35:35 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3FE20A2B.6020607@cisco.com> References: <3FE20A2B.6020607@cisco.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1062A648-31A2-11D8-96B9-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] Date: Thu, 18 Dec 2003 22:35:13 +0100 To: Eliot Lear X-Mailer: Apple Mail (2.606) 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 18-dec-03, at 21:12, Eliot Lear wrote: > (hopefully) the document contains some questions that can be used to > evaluate such minor issues as deployability, security, performance, > and generality. :-) I found another one: TCP and UDP checksum calculation offloading. It seems this is pretty common these days: I have a box with a turn of the century NIC and FreeBSD tells me it is offloading both rx and tx checksums. (It works too: dire tcpdump warnings when running verbose enough as outgoing packets have invalid checksums as seen by BPF.) With any multihoming solution that allows rewriting of addresses between the moment the checksum calculation is done and the moment the packet is transmitted/received, checksum offloading will pretty much have to be a thing of the past, unless we want to start doing some complex incremental updating in different places. So which is preferable? Keep it simple but lose hardware support for checksumming, or keep hardware support but add more complexity? Note that the processing for the TCP/UDP checksum is simple enough that it's probably free when doing a memcopy anyway. From owner-multi6@ops.ietf.org Fri Dec 19 05:42:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03148 for ; Fri, 19 Dec 2003 05:42:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AXI2z-000CDN-LM for multi6-data@psg.com; Fri, 19 Dec 2003 10:39:53 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AXI2m-000CCW-FE for multi6@ops.ietf.org; Fri, 19 Dec 2003 10:39:40 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBJAdTPg044428; Fri, 19 Dec 2003 10:39:29 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 hBJAdS1W176630; Fri, 19 Dec 2003 11:39:29 +0100 Received: from zurich.ibm.com ([9.145.247.82]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA23638; Fri, 19 Dec 2003 11:39:27 +0100 Message-ID: <3FE2D524.412C00D5@zurich.ibm.com> Date: Fri, 19 Dec 2003 11:38:28 +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: Eliot Lear CC: Tony Li , Multi6 Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] References: <3FE20A2B.6020607@cisco.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 Yep. I don't think Kurtis and I have any problem with listing IPv4 applicability as something to think about. We just don't want it to accidentally become a firm decision criterion. Brian Eliot Lear wrote: > > Let's leave the legaleze out of this, but (hopefully) the document > contains some questions that can be used to evaluate such minor issues > as deployability, security, performance, and generality. The methods > used might cause some conflict between these objectives. That's okay. > We can decide which ones are important when we understand which > tradeoffs are being made. > > Eliot > ps: I'm leaving the "for instances..." out for brevity's sake. > > Tony Li wrote: > > > > Brian, > > > > I thought that the point of this document was things to think about, > > not a set of decision criteria. If it is a set of criteria, then aren't > > we duplicating the requirements draft? No, I don't want to reopen that, > > but what I *AM* suggesting is that Eliot's list is literally a list > > of discussion questions. As such, I think that this is a fine question > > to ask. > > > > If you're elevating this draft as anything other than a set of > > discussion questions, then we need to have a different discussion. > > > > Which is it? > > > > Tony > > > > > > | -----Original Message----- > > | From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > > | Sent: Thursday, December 18, 2003 12:54 AM > > | To: Multi6 > > | Subject: Re: [Fwd: I-D > > | ACTION:draft-lear-multi6-things-to-think-about-00.txt] > > | > > | > > | Pekka Savola wrote: > > | > > > | > On Tue, 16 Dec 2003, Tony Li wrote: > > | > > I'd submit that if it cannot be easily ported back to > > | IPv4, that it > > | > > bears closer examination. v4 and v6 are architecturally very > > | > > similar. Any solution that does not apply to both is either a > > | > > kludge or is exploiting an odd property of one of the two. In > > | > > either case, it would bear close examination. You know, the kind > > | > > that you give things when the fire alarm in the building > > | goes off... > > | > > ? ;-) > > | > > > | > I have to heartily disagree here. IPv6 address *does* > > | have more bits. > > | > Different problem spaces have leveraged that property > > | before as well, > > | > leading to solutions which are not easily backportable to IPv4. > > | > > > | > Maybe one could reword this differently: the solution beas some > > | > thinking about if it doesn't rely on the 128bit address length of > > | > IPv6, and is not easily IPv4-capable. > > | > > | Yes. But this is the IPv6 multihoming WG, so while applicability to > > | IPv4 is an interesting question to ask, it cannot be a decision > > | criterion. > > | > > | I would counter-argue against Tony in another way. If we had variable > > | length addresses (as some people strongly suggested for IPng) a whole > > | new class of multihoming solutions might be available. But we don't, > > | so they aren't. Thus, you cannot argue that solutions *must* > > | be independent > > | of address length considerations. > > | > > | (Please don't kick off a thread on variable length addresses... at > > | least not here.) > > | > > | Brian From owner-multi6@ops.ietf.org Fri Dec 19 05:43:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03227 for ; Fri, 19 Dec 2003 05:43:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AXI1Y-000C3v-UL for multi6-data@psg.com; Fri, 19 Dec 2003 10:38:24 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AXI1A-000C2k-FI for multi6@ops.ietf.org; Fri, 19 Dec 2003 10:38:00 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBJAbnGs080278; Fri, 19 Dec 2003 10:37: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 hBJAbm1W203546; Fri, 19 Dec 2003 11:37:49 +0100 Received: from zurich.ibm.com ([9.145.247.82]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA32914; Fri, 19 Dec 2003 11:37:47 +0100 Message-ID: <3FE2D4C0.B7500C04@zurich.ibm.com> Date: Fri, 19 Dec 2003 11:36: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: Iljitsch van Beijnum CC: Multi6 List Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] References: <3FE20A2B.6020607@cisco.com> <1062A648-31A2-11D8-96B9-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.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch, From the product people I talk to, if we break offload (including the more sophisticated forms of offload such as RDDP) the solution won't be going anywhere. I think that is related to the point we discussed a couple of weeks ago about virtualized end points - a model that only works with a traditional software stack in a traditional single host simply doesn't work in today's world of virtualized server farms with load balancers and offload devices. Brian Iljitsch van Beijnum wrote: > > On 18-dec-03, at 21:12, Eliot Lear wrote: > > > (hopefully) the document contains some questions that can be used to > > evaluate such minor issues as deployability, security, performance, > > and generality. > > :-) > > I found another one: TCP and UDP checksum calculation offloading. It > seems this is pretty common these days: I have a box with a turn of the > century NIC and FreeBSD tells me it is offloading both rx and tx > checksums. (It works too: dire tcpdump warnings when running verbose > enough as outgoing packets have invalid checksums as seen by BPF.) > > With any multihoming solution that allows rewriting of addresses > between the moment the checksum calculation is done and the moment the > packet is transmitted/received, checksum offloading will pretty much > have to be a thing of the past, unless we want to start doing some > complex incremental updating in different places. > > So which is preferable? Keep it simple but lose hardware support for > checksumming, or keep hardware support but add more complexity? > > Note that the processing for the TCP/UDP checksum is simple enough that > it's probably free when doing a memcopy anyway. From owner-multi6@ops.ietf.org Fri Dec 19 05:50:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03399 for ; Fri, 19 Dec 2003 05:50:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AXIBb-000DAa-DK for multi6-data@psg.com; Fri, 19 Dec 2003 10:48:47 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AXIBN-000D6J-7G for multi6@ops.ietf.org; Fri, 19 Dec 2003 10:48:33 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBJAmSjB086336; Fri, 19 Dec 2003 10:48:29 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 hBJAmM1W278888; Fri, 19 Dec 2003 11:48:23 +0100 Received: from zurich.ibm.com ([9.145.247.82]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA28906; Fri, 19 Dec 2003 11:48:19 +0100 Message-ID: <3FE2D738.94228610@zurich.ibm.com> Date: Fri, 19 Dec 2003 11:47:20 +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: Spencer Dawkins CC: Multi6 Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] References: <3FE16B39.EA6D5EA5@zurich.ibm.com> <05cc01c3c565$d3a54ba0$0400a8c0@DFNJGL21> 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 inline... Spencer Dawkins wrote: > > I may be misunderstanding something here, so let me ask the question > before I expound. > > ----- Original Message ----- > From: "Brian E Carpenter" > To: "Multi6" > Sent: Thursday, December 18, 2003 2:54 AM > Subject: Re: [Fwd: I-D > ACTION:draft-lear-multi6-things-to-think-about-00.txt] > > > Pekka Savola wrote: > > > > > > Maybe one could reword this differently: the solution beas some > > > thinking about if it doesn't rely on the 128bit address length of > > > IPv6, and is not easily IPv4-capable. > > > > Yes. But this is the IPv6 multihoming WG, so while applicability to > > IPv4 is an interesting question to ask, it cannot be a decision > > criterion. > > I'm not sure what the difference between "bears some thinking about" > and "being a decision criterion" is in Brian's mind. > > What I'm hoping Brian is saying is, "it's OK to notice whether a > proposal works for IPv4, on this mailing list, but 'doesn't work for > IPv4' can't be used to disqualify a proposal". That's what I think I'm saying. > > The reason I'm asking is, I've been very aware that multi6 was willing > to host discussions at the very edge of the WG's charter, because > multi6 was the "least wrong" place to have these discussions. Sean > Doran (former WG chair) said basically, "why the heck not?" on August > 9, in the "loc/id split" thread. We do owe the WG a draft new charter where this should be clarified. Working, working... > > If Brian is saying that discussions about IPv4 suitability don't > belong here, we need to find a place where they do belong. The current charter already says 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. So yes, I think specifics about IPv4 solutions belong elsewhere. But if an IPv6 solution would also work for IPv4, that would be a fine result. > > I THOUGHT that Leslie asked Geoff to set up a mailing list after the > IAB workshop in Vienna, but the minutes at > http://www.ietf.org/proceedings/03jul/127.htm don't show this action > item. So, as Sean said, this is the least wrong place that exists > today - how wrong is it? Well, I think that list exists: https://www1.ietf.org/mailman/listinfo/saad but it has been quiet. Brian From owner-multi6@ops.ietf.org Fri Dec 19 05:57:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03493 for ; Fri, 19 Dec 2003 05:57:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AXIIT-000EKF-Mk for multi6-data@psg.com; Fri, 19 Dec 2003 10:55:53 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AXIIG-000EJG-JC for multi6@ops.ietf.org; Fri, 19 Dec 2003 10:55:40 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBJAtSn0118068; Fri, 19 Dec 2003 10:55:28 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 hBJAtS1W288638; Fri, 19 Dec 2003 11:55:28 +0100 Received: from zurich.ibm.com ([9.145.247.82]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA29000; Fri, 19 Dec 2003 11:55:26 +0100 Message-ID: <3FE2D8E4.DF239DFF@zurich.ibm.com> Date: Fri, 19 Dec 2003 11:54:28 +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: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] References: <3FE16B39.EA6D5EA5@zurich.ibm.com> <7284DA2E-3165-11D8-96B9-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.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On 18-dec-03, at 9:54, Brian E Carpenter wrote: > > > I would counter-argue against Tony in another way. If we had variable > > length addresses (as some people strongly suggested for IPng) a whole > > new class of multihoming solutions might be available. But we don't, > > so they aren't. Thus, you cannot argue that solutions *must* be > > independent > > of address length considerations. > > > (Please don't kick off a thread on variable length addresses... at > > least not here.) > > Why not? > > I think that if we can do what we need to do by using variable length > addressing, then the annoyance of having to cram those inside an IPv6 > packet in a way that the packet remains routable is probably worth it. Having proposed exactly that in 1994 as an extension to IPv4, I can hardly disagree. (See draft-carpenter-aeiou-00.txt if you can find it...) But that class of solution doesn't change the address length seen by the routing system, which IMHO is something we cannot reasonably consider. > > There is lots more in the draft that I don't feel particularly > comfortable with. For instance, the mobility questions. Send text! Brian From owner-multi6@ops.ietf.org Fri Dec 19 07:12:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05216 for ; Fri, 19 Dec 2003 07:12:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AXJSG-000Mlj-C9 for multi6-data@psg.com; Fri, 19 Dec 2003 12:10:04 +0000 Received: from [204.127.202.64] (helo=sccrmhc13.comcast.net) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AXJS1-000Mkl-WE for multi6@ops.ietf.org; Fri, 19 Dec 2003 12:09:50 +0000 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc13) with SMTP id <2003121912094901600ri40re> (Authid: sdawkins@comcast.net); Fri, 19 Dec 2003 12:09:49 +0000 Message-ID: <070301c3c629$0352c260$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Multi6" References: <3FE16B39.EA6D5EA5@zurich.ibm.com> <05cc01c3c565$d3a54ba0$0400a8c0@DFNJGL21> <3FE2D738.94228610@zurich.ibm.com> Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] Date: Fri, 19 Dec 2003 06:09:53 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.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 Wow. I missed this one completely. Thanks (and thanks to Marcelo, who sent this privately). ----- Original Message ----- From: "Brian E Carpenter" To: "Spencer Dawkins" Cc: "Multi6" Sent: Friday, December 19, 2003 4:47 AM Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] > > > > I THOUGHT that Leslie asked Geoff to set up a mailing list after the > > IAB workshop in Vienna, but the minutes at > > http://www.ietf.org/proceedings/03jul/127.htm don't show this action > > item. So, as Sean said, this is the least wrong place that exists > > today - how wrong is it? > > Well, I think that list exists: > https://www1.ietf.org/mailman/listinfo/saad > but it has been quiet. Well, of course it's been quiet because all the discussion has been happening over hear, annoying multi6! :-} From owner-multi6@ops.ietf.org Fri Dec 19 15:59:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26161 for ; Fri, 19 Dec 2003 15:59:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AXReo-00053T-JT for multi6-data@psg.com; Fri, 19 Dec 2003 20:55:34 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AXReW-00051t-O0 for multi6@ops.ietf.org; Fri, 19 Dec 2003 20:55:16 +0000 Received: from jurassic.eng.sun.com ([129.146.86.38]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hBJKt10H019230; Fri, 19 Dec 2003 12:55:01 -0800 (PST) Received: from jurassic.Eng.Sun.COM (esun1es-fe-ge0.Holland.Sun.COM [129.159.36.22]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hBJKspfI954453; Fri, 19 Dec 2003 12:54:56 -0800 (PST) From: Erik Nordmark Message-Id: <200312192054.hBJKspfI954453@jurassic.eng.sun.com> Date: Fri, 19 Dec 2003 12:55:01 -0800 To: "Iljitsch van Beijnum" , "Eliot Lear" Cc: "Multi6 List" Reply-To: Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] X-Mailer: Sun NetMail 2.3 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 >With any multihoming solution that allows rewriting of addresses >between the moment the checksum calculation is done and the moment the >packet is transmitted/received, checksum offloading will pretty much >have to be a thing of the past, unless we want to start doing some >complex incremental updating in different places. I think whether checksum offloading is affected or not is a function of exactly how checksum offloading is implemented. I know one vendors implementation of checksum offload that wouldn't have a problem - because software is capable of compensating for differences between the IP addresses in the IP header and in the TCP pseudo-header in order to properly handling routing headers. I don't know to what extent the same flexibility exist for other vendors. Erik From owner-multi6@ops.ietf.org Sun Dec 21 05:32:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20592 for ; Sun, 21 Dec 2003 05:32:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD) id 1AY0qD-000Pwc-ON for multi6-data@psg.com; Sun, 21 Dec 2003 10:29:41 +0000 Received: from [195.212.29.154] (helo=mtagate5.de.ibm.com) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AY0px-000Pvf-Ms for multi6@ops.ietf.org; Sun, 21 Dec 2003 10:29:25 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged)) by mtagate5.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBLAT6Gs126928; Sun, 21 Dec 2003 10:29:06 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 hBLAT5A3275450; Sun, 21 Dec 2003 11:29:05 +0100 Received: from zurich.ibm.com ([9.145.172.107]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA16368; Sun, 21 Dec 2003 11:29:01 +0100 Message-ID: <3FE575B3.9FC1FEB4@zurich.ibm.com> Date: Sun, 21 Dec 2003 11:28:03 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: erik.nordmark@Sun.COM CC: Iljitsch van Beijnum , Eliot Lear , Multi6 List Subject: Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt] References: <200312192054.hBJKspfI954453@jurassic.eng.sun.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 Erik Nordmark wrote: > > >With any multihoming solution that allows rewriting of addresses > >between the moment the checksum calculation is done and the moment the > >packet is transmitted/received, checksum offloading will pretty much > >have to be a thing of the past, unless we want to start doing some > >complex incremental updating in different places. > > I think whether checksum offloading is affected or not is a function of > exactly how checksum offloading is implemented. > > I know one vendors implementation of checksum offload that wouldn't have > a problem - because software is capable of compensating for differences > between the IP addresses in the IP header and in the TCP pseudo-header > in order to properly handling routing headers. > > I don't know to what extent the same flexibility exist for other vendors. Indeed, it is undesirable to rely on product kludges in an architecture. Brian (now off-line until Jan. 5)